[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140831125745.GW12888@brightrain.aerifal.cx>
Date: Sun, 31 Aug 2014 08:57:45 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 7/8] add the thrd_xxxxxx functions
On Sun, Aug 31, 2014 at 09:57:34AM +0200, Jens Gustedt wrote:
> > > if (attrp) attr = *attrp;
> > >
> > > __acquire_ptc();
> > > @@ -234,7 +253,10 @@ static int __pthread_create(pthread_t *restrict res, const pthread_attr_t *restr
> > > new->canary = self->canary;
> > >
> > > a_inc(&libc.threads_minus_1);
> > > - ret = __clone(start, stack, flags, new, &new->tid, TP_ADJ(new), &new->tid);
> > > + if (c11)
> > > + ret = __clone(start_c11, stack, flags, new, &new->tid, TP_ADJ(new), &new->tid);
> > > + else
> > > + ret = __clone(start, stack, flags, new, &new->tid, TP_ADJ(new), &new->tid);
> >
> > Couldn't this be "c11 ? start_c11 : start" to avoid duplicating the
> > rest of the call?
>
> I think that the ternary expression together with the other
> parenthesized paramenter and the length of the line would make the
> line barely readable.
>
> This are some of the pivots lines of the implementation, I'd rather
> have them stick out.
>
> Also the assembler that is produced should be identical.
Whether or not the output is identical, your code is much less
readable and maintainable: an active effort is required by the reader
to determine that the only difference between the two code paths is
the function pointer being passed. This is why I prefer the use of ?:.
The following looks perfectly readable to me:
ret = __clone(c11 ? start_c11 : start, stack, flags,
new, &new->tid, TP_ADJ(new), &new->tid);
> > Also, since it doesn't depend on anything in pthread_create.c,
>
> It does, __THRD_C11 :)
How about naming it to __ATTRP_C11_THREAD and putting it in
pthread_impl.h then?
> > it would be nice to put it in a separate thrd_create.c. It's not a big
> > deal but it shaves off a small function in POSIX programs that don't
> > use thrd_create.
>
> I'd really prefer to keep all the logic of thrd_create together in one
> file. All the other additions at this point are tightly bound to be in
> the same TU as pthread_create, for all this weak symbol stuff that is
> going on with tsd and friends.
>
> Also see that as an incentive to accept patch 8/8 to separate both
> implementations more cleanly :)
Yes I'm aware, but I don't want gratuitous incentives for patch 8/8
just because patch 7/8 is done intentionally suboptimally. :-) If the
approaches are being compared, we should be comparing the preferred
efficient versions of both. And I'd like to wait to seriously think
about 8/8 until everything else is fully ready to commit, or
preferably already committed.
> > I'd really just prefer that all of these can't-fail cases be a
> > straight tail call with no support for nonzero thrd_success values.
> > But as long as the code is correct and the inefficiency is trivially
> > optimized out, I'm not going to spend a lot of time arguing about it.
> > I do think it's telling, though, that the (albeit minimal) complexity
> > of trying to handle the case where thrd_success is nonzero seems to
> > have caused a couple bugs -- this is part of why I don't like having
> > multiple code paths where one path is untestable/untested. To me, a
> > code path that's never going to get tested is a much bigger offense
> > than an assumption that a constant has the value we decided it has.
Do you have any thoughts on this part?
> > > diff --git a/src/thread/thrd_join.c b/src/thread/thrd_join.c
> > > new file mode 100644
> > > index 0000000..a8c7aed
> > > --- /dev/null
> > > +++ b/src/thread/thrd_join.c
> > > @@ -0,0 +1,16 @@
> > > +#include "pthread_impl.h"
> > > +#include <sys/mman.h>
> > > +#include <threads.h>
> > > +
> > > +int __munmap(void *, size_t);
> > > +
> > > +/* C11 threads cannot be canceled, so there is no need for a
> > > + cancelation function pointer, here. */
> > > +int thrd_join(thrd_t t, int *res)
> > > +{
> > > + int tmp;
> > > + while ((tmp = t->tid)) __timedwait(&t->tid, tmp, 0, 0, 0, 0, 0);
> > > + if (res) *res = (int)(intptr_t)t->result;
> > > + if (t->map_base) __munmap(t->map_base, t->map_size);
> > > + return thrd_success;
> > > +}
> >
> > I'd rather avoid duplicating this function too.
>
> No this ain't a duplicate. The cast here is necessary and plain use of
> pthread_join would have us interpret an int* as void**, so the
> assignment could potentially overwrite the second half of the word res
> is pointing to.
>
> I'll have that visually stick out with a comment
I'm aware that you can't cast the int* to void**, but you can still
implement the function as a trivial wrapper that doesn't introduce any
duplication of internal logic for cleaning up an exited thread:
int thrd_join(thrd_t t, int *res)
{
void *pthread_res;
__pthread_join(t, &pthread_res);
if (res) *res = (int)(intptr_t)pthread_res;
return thrd_success;
}
Rich
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.
