[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1406931672.8274.144.camel@eris.loria.fr>
Date: Sat, 02 Aug 2014 00:21:12 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: working C11 thread implementation
Hello,
thanks for the quick review!
Am Freitag, den 01.08.2014, 23:08 +0200 schrieb Szabolcs Nagy:
> > For the choices of the constants, for this version they are such that
> > most wrapper calls result in being tail calls. I verified this by
> > looking into the assembler that is produced. As they are now, most of
> > these tail functions could also be just provided as weak aliases. We
> > chose to implement them as functions such that in case of change of
> > the constants we only have to recompile and no other maintenance is
> > required.
> >
>
> i'd assume the constants to be right and fix up the
> code only in case of later breakage
Well, the problem is that these constants are not "constants" but come
from errno.h. This has two disadvantages:
- currently this pollutes the name space of the C thread
implementation with the E-names
- these constants are arch dependent, we would need another mechanism
to get them visible
My preferred solution to this is to make a TR to the thread
specification, by forcing the obvious choices and by allowing
threads.h to include errno.h. (The optional Annex K sets a precedent
by having errno codes as return value for functions.)
> > +int cnd_signal(cnd_t * cnd) {
> > + /* In the best of all worlds this is a tail call. */
> > + int ret = __pthread_cond_signal(cnd);
> > + if (thrd_success)
> > + return ret ? thrd_error : thrd_success;
> > + return ret;
> > +}
>
> this is a bit weird
>
> i think it's better to just assume thrd_success==0
> and static assert it somewhere as a reminder
_Static_assert would need a compiler that implements this. It would be
easier just not to introduce a dependency for the tool chain. The code
as it is, now, will get optimized out by any decent compiler, I hope.
> > +int mtx_init(mtx_t * m, int type)
> > +{
> > + *m = (pthread_mutex_t) {
> > + ._m_type = ((type&mtx_recursive) ? PTHREAD_MUTEX_RECURSIVE : 0),
> > + };
> > + return 0;
> > +}
>
> return thrd_success
nice catch, I'll change that
(same for the other similar cases below)
> > +/* This is needed because not all arch have __pthread_self as a static
> > + symbol. */
> > pthread_t pthread_self()
> > {
> > return __pthread_self();
>
> ...
>
> > +/* This is needed because not all arch have __pthread_self as a static
> > + symbol. */
> > +pthread_t thrd_current()
> > +{
> > + return __pthread_self();
> > +}
>
>
> i dont understand these comments
> you mean that they could be weak aliases otherwise?
yes something like that, I'll amend the comment
> > +/* Roughly __syscall already returns the right thing: 0 if all went
> > + well or a negative error indication, otherwise. Unfortunately the C
> > + standard foresees the special case of an interrupted call and fixes
> > + that error return to -1 (instead of introducing EINTR). */
> > +int thrd_sleep(const struct timespec *req, struct timespec *rem)
> > +{
> > + int ret = __syscall(SYS_nanosleep, req, rem);
> > + // compile time comparison, constant propagated
> > + if (EINTR != 1) {
> > + switch (ret) {
> > + case -EINTR: return -1;
> > + case -1: return -EINTR;
> > + }
> > + }
> > + // potentially a tail call
> > + return ret;
> > +}
>
> "The thrd_sleep function returns zero if the requested
> time has elapsed, -1 if it has been interrupted by a
> signal, or a negative value if it fails."
>
> this is confusing
you mean the C standards text is confusing? yes, definitively
if you mean the code is confusing, then I should explain it better :)
The idea is that if SYS_nanosleep returns -EINTR, thrd_sleep in turn
must return -1. If EINTR is in fact 1 on the arch we just can return
the value (and 0 if everthing is ok and some undefined value in other
UB cases.)
If EINTR isn't 1, we have to be careful not to return -1 for some
other error code of SYS_nanosleep, whatever happens to be error number
1. So the second case captures such an accidental -1 and sends -EINTR
(which we know not to be -1.).
> (either should not have the name thrd_ or follow
> the error enum convention of other thrd_ functions)
I am not sure that I understand what you try to say.
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.
