Re: Pending issues for next release

[Rich Felker <dalias@aerifal.cx>]

On Tue, Apr 02, 2013 at 01:42:54PM +0200, Jens Gustedt wrote:
> Hi,
> 
> 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.

> 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 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". 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.

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.

Rich