Re: [PATCH 7/8] add the thrd_xxxxxx functions

[Rich Felker <dalias@libc.org>]

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