From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9263 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: setcontext/getcontext/makecontext missing? Date: Thu, 4 Feb 2016 18:01:32 +0100 Message-ID: <20160204170131.GC9915@port70.net> References: <87199830-7260-4E33-B3A6-BE15AF610BCE@akamai.com> <20160204145409.GB9915@port70.net> <20160204154137.GN9349@brightrain.aerifal.cx> <20160204162246.GF25193@example.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1454605318 30353 80.91.229.3 (4 Feb 2016 17:01:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Feb 2016 17:01:58 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9276-gllmg-musl=m.gmane.org@lists.openwall.com Thu Feb 04 18:01:47 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aRNHu-0003Or-Ry for gllmg-musl@m.gmane.org; Thu, 04 Feb 2016 18:01:47 +0100 Original-Received: (qmail 9299 invoked by uid 550); 4 Feb 2016 17:01:44 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 9280 invoked from network); 4 Feb 2016 17:01:43 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20160204162246.GF25193@example.net> User-Agent: Mutt/1.5.24 (2015-08-30) Xref: news.gmane.org gmane.linux.lib.musl.general:9263 Archived-At: * 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