From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6031 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 7/8] add the thrd_xxxxxx functions Date: Sun, 31 Aug 2014 20:04:23 -0400 Message-ID: <20140901000423.GB12888@brightrain.aerifal.cx> References: <20140831004643.GP12888@brightrain.aerifal.cx> <1409471854.4476.272.camel@eris.loria.fr> <20140831125745.GW12888@brightrain.aerifal.cx> <1409491161.4476.283.camel@eris.loria.fr> <20140831140533.GX12888@brightrain.aerifal.cx> <1409497642.4476.289.camel@eris.loria.fr> <20140831160630.GZ12888@brightrain.aerifal.cx> <1409502960.4476.297.camel@eris.loria.fr> <20140831170245.GA12888@brightrain.aerifal.cx> <1409512246.4476.304.camel@eris.loria.fr> 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 1409529927 1639 80.91.229.3 (1 Sep 2014 00:05:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Sep 2014 00:05:27 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6038-gllmg-musl=m.gmane.org@lists.openwall.com Mon Sep 01 02:05:20 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XOF7Y-0006Lg-1J for gllmg-musl@plane.gmane.org; Mon, 01 Sep 2014 02:05:20 +0200 Original-Received: (qmail 1486 invoked by uid 550); 1 Sep 2014 00:05:13 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 1331 invoked from network); 1 Sep 2014 00:04:36 -0000 Content-Disposition: inline In-Reply-To: <1409512246.4476.304.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6031 Archived-At: On Sun, Aug 31, 2014 at 09:10:46PM +0200, Jens Gustedt wrote: > Am Sonntag, den 31.08.2014, 13:02 -0400 schrieb Rich Felker: > > On Sun, Aug 31, 2014 at 06:36:00PM +0200, Jens Gustedt wrote: > > > EAGAIN from clone is clearly a distinct error condition than when it > > > is on ENOMEM. I would not see it covered by what C11 expects as that > > > error condition. So the EAGAIN from clone should go to thrd_error, I > > > think, and not be merged with ENOMEM for the C threads implementation. > > > > I disagree here, at least unless you have a convincing argument for > > this. EAGAIN from clone reflects a condition where a resource could > > not be allocated. The reason (policy or inherent limits on a > > particular type of resource, as opposed to just generally running out > > of memory) doesn't seem to be relevant to applications, and I don't > > see how thrd_error is any more appropriate than thrd_nomem for > > reporting it. Certainly there are other cases where one type of > > allocation (e.g. mmap for a thread) might fail where another (e.g. > > malloc reusing freed memory on the heap) might fail, so I don't think > > you can say that thrd_nomem is inappropriate if malloc would succeed. > > The convincing arguments come from the documentation, I'd say. C11 > says > > The thrd_create function returns > > thrd_success on success, or > > thrd_nomem if no memory could be allocated for the thread requested, or > > thrd_error if the request could not be honored. > > (If this is a reasonable distinction of errors is a completely > different question.) > > The man page for clone (whatever authority this has) says, among other > things > > EAGAIN Too many processes are already running. > > ENOMEM Cannot allocate sufficient memory to allocate a task > structure for the child, or to copy those parts of the > caller's context that need to be copied. > > I have difficulties to read "lack of other resources" into the case > for thrd_nomem. I see that EAGAIN is relatively well covered by > thrd_error, but not very well by thrd_nomem. thrd_nomem is the > catch-all-the-rest error, so I think that C11 permits to map EAGAIN > together with eventually happening other exotic stuff on on it. It should be noted that mmap/mprotect, as used by pthread_create, can experience ENOMEM without memory exhaustion, as a result of a separate limit: the kernel's limit on the number of VMAs a process can have. By default I think this is something like 64k, and each thread with a guard page uses two. I don't see how hitting the VMA limit is significantly different than hidding the kernel task ("process") limit. The reason I bring this up is because the VMA limit is indistinguishable, at the syscall level, from memory exhaustion -- both cases give ENOMEM. In both cases -- EAGAIN for pthread_create and thrd_nomem for thrd_create, the error tells the application something useful: that the failure is potentially transient. Whether it's actually transient depends a lot on the application; if the app has a lot of memory tied up that won't be freed asynchronously, then it's unlikely to be transient, but if the app has threads responding to asynchronous events (like requests from the network) it's very possible that the needed resource will be available as soon as some of them complete. Rich