From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6019 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 13:02:45 -0400 Message-ID: <20140831170245.GA12888@brightrain.aerifal.cx> References: <22215ff2f880382340930f78cc746565a625a806.1409423162.git.Jens.Gustedt@inria.fr> <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> 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 1409504586 12814 80.91.229.3 (31 Aug 2014 17:03:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 31 Aug 2014 17:03:06 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6026-gllmg-musl=m.gmane.org@lists.openwall.com Sun Aug 31 19:02:59 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 1XO8Wp-0001ai-0Z for gllmg-musl@plane.gmane.org; Sun, 31 Aug 2014 19:02:59 +0200 Original-Received: (qmail 13584 invoked by uid 550); 31 Aug 2014 17:02:57 -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 13573 invoked from network); 31 Aug 2014 17:02:57 -0000 Content-Disposition: inline In-Reply-To: <1409502960.4476.297.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:6019 Archived-At: On Sun, Aug 31, 2014 at 06:36:00PM +0200, Jens Gustedt wrote: > > > > > But I just discovered another such incentive :) You were right, that > > > > > the error handling for thrd_create was not correct for C11, but it > > > > > wasn't my fault :) POSIX (and thus __pthread_create) basically maps > > > > > all errors to EAGAIN, where C11 requires us to distinguish ENOMEM from > > > > > other failures. > > > > > > > > > > Thus I had to integrate this difference into __pthread_create, which > > > > > was not difficult, but which intrudes even a little bit more into the > > > > > existing code. > > > > > > > > I think POSIX's EAGAIN is fully equivalent to C11's thrd_nomem: both > > > > should reflect any condition where the thread could not be created due > > > > to a resource exhaustion type failure. While you could argue that > > > > thrd_nomem should only indicate failure of the mmap, not the clone, I > > > > think this would be a useless distinction to callers (both of them are > > > > fundamentally allocation operations) and then you'd be forced to use > > > > thrd_error for clone failures, whereas I would think thrd_error should > > > > be reserved for either erroneous usage (but that's UB anyway) or more > > > > permanent failures (like lack of thread support on the OS). > > > > > > Having read up a bit, now, I don't think so, for C threads this > > > mapping is not correct. clone has several different error returns > > > that the actual code correctly maps to EAGAIN, but among them it also > > > has ENOMEM. > > > > > > So we have possible ENOMEM coming from clone and from mmap, and a > > > bunch of other obscure errors that should go to thrd_error. > > > > Like what? I see no possible errors except EAGAIN and ENOMEM. The only > > others listed in the man page are EINVAL and EPERM and they pertain to > > invalid arguments that aren't being used by pthread_create. > > (I withdraw the "bunch of") > > 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. Rich