Date: Tue, 2 Apr 2013 14:09:36 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Pending issues for next release 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
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.