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,
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
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk