From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9265 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: setcontext/getcontext/makecontext missing? Date: Thu, 4 Feb 2016 14:24:03 -0500 Message-ID: <20160204192403.GR9349@brightrain.aerifal.cx> 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 1454613875 16725 80.91.229.3 (4 Feb 2016 19:24:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Feb 2016 19:24:35 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9278-gllmg-musl=m.gmane.org@lists.openwall.com Thu Feb 04 20:24:24 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 1aRPVr-0001nA-M1 for gllmg-musl@m.gmane.org; Thu, 04 Feb 2016 20:24:19 +0100 Original-Received: (qmail 1959 invoked by uid 550); 4 Feb 2016 19:24:17 -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 1927 invoked from network); 4 Feb 2016 19:24:16 -0000 Content-Disposition: inline In-Reply-To: <20160204162246.GF25193@example.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9265 Archived-At: On Thu, Feb 04, 2016 at 05:22:47PM +0100, u-uy74@aetey.se wrote: > 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. > > 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. In theory, userspace context switching could possibly be slightly faster than threads. However the ucontext API saves/restores the signal mask as part of context switching, which inherently requires a syscall. (There are possibly ways we could cache the most-recently-set signal mask in TLS and avoid redundant setting, but no existing libcs do this, and it sounds mildly difficult/error-prone.) Thus the comparison is not between pure-userspace switching and having the kernel involved, but between a SYS_rt_sigprocmask syscall and a voluntary context switch between threads in the same process. The latter is extremely light and comparable to some of the cheapest syscalls, so I suspect the performance difference between ucontext and threads is negligible. Given that there are a lot of other good reasons you should be using threads instead of ucontext, I think the matter is pretty clear. Rich