[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1406363575.6438.97.camel@eris.loria.fr>
Date: Sat, 26 Jul 2014 10:32:55 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: C11 threads
Am Samstag, den 26.07.2014, 03:35 -0400 schrieb Rich Felker:
> On Sat, Jul 26, 2014 at 09:16:40AM +0200, Jens Gustedt wrote:
> > The approach with weak aliases only works if the return codes of the
> > functions agree. We need
> >
> > enum {
> > thrd_success = 0,
> > thrd_busy = EBUSY,
> > thrd_error = EINVAL,
> > thrd_nomem = ENOMEM,
> > thrd_timedout = ETIMEDOUT,
> > };
> >
> > and I don't think that there is much of a sensible way to do that
> > differently. Already the naming of the constants suggest that these
> > are the values that people (who?) had in mind when designing these
> > interfaces.
>
> Actually, I disagree with your mappings. thrd_error is not going to
> come from EINVAL (IIRC the only place POSIX specifies EINVAL anyway is
> as an optional error when you already invoked UB) but rather from
> attempting to lock a recursive mutex when the count is already maxed
> out.
I checked for all the functions that I marked for being suitable to be
aliased and that return int, and my impression was EINVAl was the only
error that could occur and that it was consistent with
thrd_error, and that other return values from POSIX functions such as
EDEADLK decribe behavior that is UB for C11.
But it seems I missed EAGAIN for recursive mutexes. I will reconsider.
> And thrd_nomem is not going to come from ENOMEM, since
> pthread_create returns EAGAIN, not ENOMEM, when memory for the thread
> cannot be allocated.
thrd_create can't be an alias, anyhow, so there is no problem in
translating return values.
(BTW, the C11 semantics for what thrd_nomem would mean are fuzzy
enought that returning thrd_error in all error cases would be
sufficient, I think)
Other functions that have return conventions that are not easily to
bring in line with POSIX are mtx_unlock and thrd_sleep, so they need
wrappers, too.
> With this in mind, your idea of using errno codes is seeming less and
> less reasonable to me.
>
> For reference, here's a summary of the only possible errors I see:
>
> thrd_timedout - for timed operations
>
> thrd_busy - for mtx_trylock
>
> thrd_error - for mtx_lock or trylock (maxed recursive lock count), or
> tss_create (no more tss slots)
>
> thrd_nomem - for thrd_create
>
> All of the other cases looked like things that cannot happen with musl
> (or with any reasonable implementation).
>
> > > Obviously if the error values are used directly, duplicating them in
> > > another header is more trouble since they vary per-arch. This is part
> > > of why I would actually prefer not to use them for the thread function
> > > result codes, but which we do will depend on which way glibc does it.
> > > I can check in with them and see if they have a plan yet.
> >
> > yes, that would be good
> >
> > I, on my site, will try to have something added to the C specification
> > that threads.h also includes errno.h. For the moment it is only
> > specified that it does so with time.h.
> >
> > Perhaps it would even be good to have the thrd-constants also be
> > exported by errno.h. These are error codes, finally.
>
> I disagree here. There are many different kinds of result codes in C
> and POSIX which are in different domains. If the thrd_* result codes
> had been intended to be in the same domain as errno values, these
> functions would have just been specified to return errno values.
no.
Whereas you can normally suppose that additions to the C standard are
deeply discussed for all their implications with the existing parts,
historically this seems not to be the case for C11 threads.
The interface specification is just an artefact of being the one of a
proprietary library that existed at that time. That one had the
head-start of having two members of the committee being the owners of
the company that owns that library. (Probably these people had good
intentions, though. The discussion between the committee and the C
user community is simply not organized well.)
The starting point for C11 threads just was the reference manual of
that library, and the process of standardization only corrected the
most obvious incoherences. (E.g the fact that it used (but didn't
define) yet another type to specify times.)
Anybody with reason and with knowledge of POSIX and C (which are
standards from the same organization, ISO) would just have specified
error codes in line with pthreads. There are not many places in the
standard that uses enumeration constants for a similar purpose, and it
has not much of an advantage. There is the general requirement of the
standard that all constant integer expressions that it defines must be
testable by the preprocessor.
> It's
> possible that they might match errno values, but that's certainly an
> implementation detail, not something that applications could
> reasonably depend on, and therefore I think it makes no sense to
> require or allow threads.h to expose errno.h.
As you can see I strongly disagree here. We shouldn't introduce values
that semantically serve as error return values of library functions
and that are not regulated by errno.h and that aren't fixed in
compilation phase 3.
Jens
--
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
