> On Thu, 2008-09-04 at 11:18 -0400, Steve Huston wrote: > > > * Alan Conway <[EMAIL PROTECTED]> [09/04/08 07:51]: > > > > So my suggestion: if boost::time solves your problem on > > > > windows then do > > > > a new sys/boost/Time.cpp impl using boost::time, so no > > > > impact on other code. > > > > That's essentially the path I've taken... But the first time a timed > > condition wait was tried, boost threw an out-of-range time > exception. > > > > The Windows Mutex, Condition, etc. are boost-based. So I guess it > > could be moved to sys/boost. > > At this point I think the pthreads code is well tested and is very > portable to many platforms - I would be against replacing it with a > boost implementation. Especially as on these same platforms the boost > implementation will just sit on top of the pthreads implementation > anyway (in most cases).
Right - to be clear, I wasn't looking to replace pthreads with boost. > Also pthreads is well documented (in books even), and boost is still > subject to change. If these things make it into the C++ > standard lib as > has been threatened then I'll argue strongly to use that, but I don't > see any value in changing from pthread to boost for those > platforms that are sufficiently posix. Right - as long as the platform implements the same Pthreads standard/draft as RHEL 4/5, great. > > > > > That's been working well for me. I've been playing around > > > with making a boost > > > "port" in sys/boost since I'll eventually need an OSX client > > > too and I figured > > > it was easiest to let boost handle as much of the native code > > > as possible. > > If I'm not mistaken OSX, being unix essentially, will already have > pthreads. But which one? I don't know the answer... Just noting that not all Pthreads are created equal. -Steve
