Re: FreeBSD's Google Summer of Code 2016

[Pedro Giffuni <pfg@FreeBSD.org>]

On 03/05/16 19:31, Rich Felker wrote:
> On Sat, Mar 05, 2016 at 07:25:47PM -0500, Rich Felker wrote:
>> On Sat, Mar 05, 2016 at 07:14:34PM -0500, Pedro Giffuni wrote:
>>>
>>>
>>> On 03/05/16 18:32, Rich Felker wrote:
>>>> On Sat, Mar 05, 2016 at 05:41:25PM -0500, Pedro Giffuni wrote:
>>>>> First of all, great to hear there is interest on the musl side too.
>>>>>
>>>>> I think the biggest precedent of porting linux-oriented C libraries
>>>>> came from Debian's kFreeBSD. We accomodated a little by for them
>>>>> by defining __FreeBSD_kernel__ in sys/param.h.
>>>>>
>>>>> While using the optional linux-abi futex in FreeBSD could be an option,
>>>>> it is not really the cleanest option. The Debian guys did a port of
>>>>> NPTL using regular pthreads:
>>>>>
>>>
>>> Of course I ahould have meant "based on regular FreeBSD kernel services".
>>>
>>>>> http://thread.gmane.org/gmane.linux.debian.ports.bsd/11702
>>>>>
>>>>> I am certain this will require more research but it would be useful
>>>>> for other ports as well.
>>>>
>>>
>>> We could ask Petr Salinger for the details, but I am pretty sure
>>> FreeBSD has the required functionality natively.
>>>
>>>> Glibc/NPTL has a lot of what I'd call "gratuitous abstraction" (like
>>>> the lll stuff) in their pthread primitives which makes this
>>>> "possible". I call it gratuitous because it's really really hard to
>>>> achieve correct implementations of the pthread sync primitives that
>>>> don't have serious corner-case bugs, and it's unlikely that their
>>>> abstractions actually suffice to make correct alternate
>>>> implementations.
>>>>
>>>> musl does not have any such abstraction. We require a compare-and-swap
>>>> operation or equivalent on which arbitrary atomic operations can be
>>>> constructed, a futex or equivalent operation that's roughly
>>>> while(*addr==expected) sleep(), and implement all the sync primitives
>>>> just once on top of these.
>>>>
>>>
>>> I am not a threading expert (or even a CS guy), but it sounds like
>>> mutex(9) with condvar(9) would do [1]:
>>
>> No, they don't satisfy the needs of musl; they have their own
>> additional storage requirements and are probably not AS-safe. It might
>> be possible to use them to implement a userspace-emulated futex queue
>> (only if they are AS-safe), but I don't see a way to extend that to
>> the process-shared case.
>
> Actually these look like kernelspace APIs, not userspace, unless I'm
> mistaken. In that case I don't see how they're relevant/usable. Is tht
> correct?
>

Ugh .. yeah ... sem(9) is kernel only API too.

The best is to look at the native thread library, not precisely
the easiest to read code in the world, I'm afraid.

OpenGrok may help:

http://src.illumos.org/source/xref/freebsd-head/lib/libthr/

Pedro.