Re: Win32 Conditional support

[David Sugar]

I am a little less confident about the usability of the pthread-win32 
port.  I recall historically the cygwin testing of Common C++ has always 
uncovered broken or incomplete implimentation of pthread code there.  In 
fact, even very recently, we would find segfaults in the cygwin pthread 
Common C++ test apps and we were never able to get an implimentation to 
compile and complete all regression tests successfully unlike other 
pthread platforms that had been tested successfully.  The mingw32 
cross-compile, which used the native win32 threads, would build test 
executables that have successfully completed all the standard regression 
tests, and I presume the pure native build does the same.

There is a worthwhile point that pthread is a layer on top of the native 
mechanisms, and as such, it means win32 platform code becomes removed by 
yet one more layer from the actual implimentation.  Since there is no 
benefit to freedom in the win32 port in compiling to something that 
itself is linked to the native methods anyway as to doing so directly, I 
fail to see any immediate benefit that would be derived from using 
pthread-win32.

The question that remains is if the behavior is the same.  Since the 
pthread-win32 port already has different behavior than some pthread 
implimentations, there is no clear win here either.  Common C++ also 
maintains consistent behavior at the abstract level above the native 
threading, and so applications built on a win32 native target do where 
we can make it behave the same as those built for some of the MANY 
pthread implimentations found in the posix world, many of which are also 
in subtle ways broken or incomplete.  I fully agree we need conditional 
support to be consistent between the win32 and posix platforms, and I 
think we should see if this can be done by the native calls directly.  I 
would presume it can be done if the pthread-win32 port can do this.

Federico Montesino Pouzols wrote:

>   Hi,
>
>  
>
> > Has anyone started work on providing support for Conditional objects on
> > the Win32 platform?
> >
> > Would it make sense for common c++ to simply leverage the existing
> > pthreads implementation for win32 at
> > http://sources.redhat.com/pthreads-win32/.  It looks to be a pretty
> > complete implementation that has support for condition variables, among
> > other things.
> >
> >    
>
>   Well, using pthreads-win32 as the base to implement CC++'s conditionals
> would imply changing the whole threading/synchronization Win32
> implementation of CC++. Currently, the Win32 port of CC++ is based on
> "native" Win32 calls, so we are talking of a very deep change.
>
>   Sometime ago I used pthreads-win32 and it certainly works quite well
> and stable. There would be however three issues if CC++ based its Win32
> port on pthreads-win32:
>
>   * We would impose an additional dependency for a core component of CC++.
>   * We would have three layers (CC++/pthreads-win32/Win32 native). I do
> not know pthreads-win32 internals so as to say if performance would
> degrade significantly.
>   * I am not sure if pthreads-win32 would be able to support all CC++
> threading features. There have been some problems with cygwin emulation
> layer.
>
>   With this I do not want to say using pthreads-win32 is a bad idea,
> but I think it would be simpler to implement Conditional with just
> Win32 system calls.
>
>  
>
> > Personally, I would be happy with a win32 common c++ that simply linked
> > against the win32 pthreads library as this would give me equivalent
> > behavior between win32 and unix.  I'm not a big fan of the native Win32
> > threading API.
> >
> > --Scott
> >
> >
> >
> > _______________________________________________
> > Bug-commoncpp mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/bug-commoncpp
> >    
>
>
>
>
>
> _______________________________________________
> Bug-commoncpp mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-commoncpp
>