Re: [boost] Boost.Threads, N2178, N2184, et al

From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2007-03-22 04:30:38

Peter Dimov wrote:
> Anthony Williams wrote:
>
>> For a non-pthreads platform, it might make sense to implement
>> pthreads in terms of the C++ interface, which is implementes in terms
>> of the native API, rather than implement the C++ interface in terms
>> of pthreads, which is then implemented in terms of the native API.
>
> Yes, this is possible, and there are no technical reasons to avoid
> this implementation approach. There are, how should I put that,
> ideological reasons to not target non-pthread platforms directly,
> though.

Wow, this caught my eye when lurking around. Are we promoting 
Windows-bashing for its own sake here ;-)

> At some point we need to draw a line and say: this is the
> thread abstraction we're coding against, and could vendors please get
> along with the program?

So, what about sockets, asynchronous I/O etc?

<with some twinkle in eye>
For asynch I/O I'd promote to code against the NT abstraction, where the OS 
was built and designed from ground up with asynchronous I/O support in the 
kernel. Or, even better, the superior VMS I/O model. And then, vendors 
should implement SYS$QIO, SYS$WAIT, SYS$SYNCH, et al ...
</with some twinkle in eye>

>
> This stance is obviously unsustainable if there are strong technical
> reasons against it. But I think that there aren't.

I'd be surprised if there were no performance considerations at all. I 
realize that C programmers also need portable threading support, but 
requiring the C++ implementation to use a specific underlying API is not the 
way to go, IMHO.

>
>> Lets take call_once, for example. PThreads only allows a real
>> function with no parameters returning void as the once function. This
>> is relatively easy to implement on top of a C++-style call_once that
>> allows arbitrary function objects with parameters, whereas it is much
>> harder to do the reverse.
>
> There is a note in N2178 that shows how to implement call_once on top
> of pthread_once2_np. ;-)

Almost everything is possible with lots of effort. I don't know about this 
particular case.

/ Johan