|
Message-ID: <20160204170131.GC9915@port70.net> Date: Thu, 4 Feb 2016 18:01:32 +0100 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: setcontext/getcontext/makecontext missing? * u-uy74@...ey.se <u-uy74@...ey.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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.