[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1364931639.18703.5.camel@eris.loria.fr>
Date: Tue, 02 Apr 2013 21:40:47 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: Pending issues for next release
Hello,
Am Dienstag, den 02.04.2013, 14:09 -0400 schrieb Rich Felker:
> On Tue, Apr 02, 2013 at 01:42:54PM +0200, Jens Gustedt wrote:
> > is there a schedule for C11 thread interfaces? I have a shallow
> > wrapping of C11 threads via pthread in P99, but because of the
> > different calling conventions for the user's start function (return of
> > int instead of void* ) this is sort of suboptimal (read crude).
>
> The easiest way to hack it on is to use a fixed start-function and
> malloc a block for the C11 thread identifier that contains the
> caller's start function and argument and space for the return value,
> then pass that to the start-function. But I agree this is ugly and
> bloated.
Basically this is what I am doing, but then there is this little
detail of pre-existing threads, in particular the one for main, that
makes that even uglier.
> > Having scanned through the musl sources, I don't think that supporting
> > C11 threads would be a big deal. Some additional wrappers should
> > suffice, I think.
>
> The main difficulty is respecting the namespace. Some functions would
> need to be renamed to be in the reserved namespace with aliases for
> their POSIX names.
I we just talk of the 'thrd_' functions, first, I think that just
aliases wouldn't do the trick. They have different calling conventions
and interpretation of the return values (thrd_yield e.g), so a
decision would have to be made where to split things. My first idea
would be to have the shared code in static functions and have a
wrapper for each interface specification.
> > I have seen Rich's mail to glibc asking for the size of some data
> > structures, but I have the impression that this has stalled and that
> > there is no reply to be expected soon.
>
> Yes...
>
> > I understand that musl wants to
> > be ABI compatible, but I don't see anything that can't be fixed
> > immediately, once they ship a version of C11 threads. I would expect
>
> This should probably be discussed in a bit more detail. Obviously
> there's the C++ ABI issue (underlying struct tags) but we haven't
> addressed that at all anyway. The ABI issues in terms of struct size
> do not actually affect the app-to-libc ABI at all; they just affect
> the ABI between object files compiled using musl's headers.
>
> > any sane implementation that supports pthread and C11 thread
> > simultaneously not to change the ABI for the native C interface just
> > for the fun of it.
>
> I'm not sure what you mean by "change".
By change I meant to use a different implementation for mtx_t than
pthread_mutex_t, e.g.
> The ABI isn't defined yet.
> There's clearly a choice to be made between making the C11 objects
> lighter, since they don't have to provide as much functionality, and
> making them just duplicates of the POSIX objects (so that code can be
> shared for both), and it's not clear which is better.
I was thinking that it would clearly be preferable to re-use the POSIX
types for the control structures (mtx_t and cnd_t) as much as
possible. If it'd just be for the fact that that code is already well
tested. But as you pose the challenge, you are right that there could
be advantages in re-implementing parts.
In particular a mtx_t being just an int and using futexes directly on
top has certainly some charm. But if you'd want to support
mtx_recursive things might get more complicated.
> Even if the objects are shared, we may choose not to share code if it
> allows the C11 synchronization primitives to have better performance
> than the POSIX ones.
performance figures that clearly distinguish two such implementations
would probably be quite difficult to obtain.
Both implementations for control structures should basically do some
instructions and one or two atomics for the fast path. For the slow
path, this then would mainly be calls to futex. So the atomics should
dominate the fast path, futex the slow path.
For thread creation we could even have the effect that C11 is
slower. C11 can't be created detached, so any thread creation for
"detached" threads has first to create a thread state somewhere that
then would be freed when detaching.
In any case we should then (shared objects, different primitives) come
up with a linker scheme that inhibits a successful linking of an
application that tries to use POSIX an C11 interfaces simultaneously.
Jens
--
:: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/ ::
:: AlGorille ::::::::::::::: office Nancy : +33 383593090 ::
:: ICube :::::::::::::: office Strasbourg : +33 368854536 ::
:: ::::::::::::::::::::::::::: gsm France : +33 651400183 ::
:: :::::::::::::::::::: gsm international : +49 15737185122 ::
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.
