qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Huston" <shus...@riverace.com>
Subject RE: c++ client - Windows port
Date Thu, 04 Sep 2008 18:27:21 GMT
> On Thu, 2008-09-04 at 11:18 -0400, Steve Huston wrote:
> > > * Alan Conway <aconway@redhat.com> [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



Mime
View raw message