Re: setcontext/getcontext/makecontext missing?

[Szabolcs Nagy <nsz@port70.net>]

* u-uy74@aetey.se <u-uy74@aetey.se> [2016-02-04 17:22:47 +0100]:
> On Thu, Feb 04, 2016 at 10:41:38AM -0500, Rich Felker wrote:
> > There's been some interest in adding them and they were on a long-term
> > goal list, but I'm not sure it makes sense anymore. All the major
> > users of this API have been moving _off_ of it, because it's
> > deprecated and impossible to use correctly - see the rationale here:
> > 
> > http://pubs.opengroup.org/onlinepubs/009695399/functions/makecontext.html
> 
> Just for the record, nevertheless it is a pity to lose them.
> 

note that the broken makecontext prototype is not the
only reason these apis are problematic:

- getcontext can return more than once (like setjmp and vfork,
this means the compiler has to recognize getcontext calls by
name and generate code more carefully around it, so if you
call it through a different name or function pointer that's
broken: local variables may get arbitrarily clobbered).
the magic names gcc knows about:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/calls.c;h=8f573b83430c52955e215e7aabcdb55cb3a76d6a;hb=HEAD#l532

- the ucontext struct passed to *context apis is not the same
as the ucontext passed to signal handlers by the kernel, but
confusingly they use the same type.
(the spec originally wanted this to work but the libc has no way
to know the kernel ucontext abi which is expanding due to new cpu
state in newer cpus.  implementations tried to fiddle with the
sigreturn syscall mechanism to make this work, but that is
problematic with sigaltstack.. e.g.
https://sourceware.org/ml/libc-alpha/2014-04/msg00006.html
so kernel and userspace ucontext cannot be mixed.)

- there was an other issue in the spec if setcontext exits the
main thread (it was not clear what cleanups will be performed).
https://sourceware.org/ml/libc-alpha/2015-03/msg00556.html

- userspace scheduling of execution threads have various issues
in general because they cannot be preemptively scheduled.
(computation loops without scheduling points can starve or
livelock the system, cooperative threads is not an easy to use
programming model. this affect all green thread runtimes from
go to erlang which indeed are usually used for io intensive
workloads not computation loops.)

> In my experience the ucontext-based implementation of user-space threads
> suits/works best for Coda file system, even though Coda can use an
> alternative pthread-based implementation of the needed threading layer.
> 
> Pthreads feels like an overkill, hardly efficient when all one needs
> is cooperative threading designed from the beginning to fit in one
> process.
> 
> Still this probably does not justify putting effort in adding this
> (apparently non-compliant) API to musl. Sigh.
> 
> Regards,
> Rune