Anthony Williams wrote:
On rereading N2178, I just spotted that your call_once has the flag as the first parameter, and allows additional arguments to be passed to the once_function. I like that, and might change my library to match.
I don't see call_once in jss_thread.zip, by the way; maybe you forgot to put it into the archive?
My focus is primarily on the C++ interface. I am concerned about the cost for implementors of requiring pthreads as the C api, but am not opposed in principle. Certainly, I think a boost.pthread-win32 library would be of benefit.
I'm very much interested in whether you support refactoring Boost.Threads to use a Boost.Pthread layer, and if so, whether you'd like to work on it. I see that you already have most of the underlying pieces in place; even your thread_data can expose an N2178 pthread.h extension interface without much effort.
As for copyable handles, my implementation is deliberately not copyable, and it would be trivial to convert it to be a copyable handle rather than just movable. If the consensus of opinion of the committee is for copyable handles, I'm happy to go with that for boost.
If we agree to pursue the pthread.h part of N2178 as part of Boost.Threads, a copyable handle can be added later without much effort and without interfering with the rest of the library.
I find it strange to template the condition var on the mutex, and then (separately) template the wait function on the lock type. I've opted for templating the whole condvar on the lock type, as it seems more coherent to me.
I actually "stole" this idea from Howard IIRC. His early version was templated on the lock. A later iteration was templated on the mutex. Both work for me.