>
> Yes, I would prefer here a native win32 API variant for threads, as
> the dependency to pthread for c++ isn't in all cases the best
> solution. Also it seems to me that the abilities of c++0x are limited
> and so a native win32 implementation should work.



That's good news!


> We have patches for OpenMP pending (Doug Semler has here prepared
> patches for this). It implements for mingw the threading by win32 API.
> He just waits that paper work for FSF gets completed. I hope this will
> happen before 4.6 gets released.
>

Perhaps Doug would like to work on this then <hopefully looking with the
most irrestable puppy eyes I can muster>?
Looking at the pthread implementation, there's only 17 functions and a few
typedefs and defines that need to be implemented, and they don't seem overly
complicated for someone with intimate knowledge of the underlying threading
API.

About the discussion in my other thread: something everyone is seemingly
missing is performance... ffmpeg/vlc has proven that native threads are much
better than a pthread-w32 implementation. This together with licensing and
dependency issues pretty much closes the case for pthreads vs win32. But
that's just my two cents...

Ruben
------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to