2010/8/25 Ruben Van Boxem <[email protected]>
> 2010/8/25 Ruben Van Boxem <[email protected]>
>
>> 2010/8/25 Kai Tietz <[email protected]>
>>
>> 2010/8/25 Ruben Van Boxem <[email protected]>:
>>> >> 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.
>>>
>>> Hope so too. He will be back soon. He has at the moment some sabbatical
>>> time.
>>>
>>> > 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...
>>>
>>> Right, performance is here for sure a second issue. The major thing
>>> for me is about pthread-w32 project, that it is slowly maintained
>>> (yes, there are patches pending over two years for review), the
>>> license issue about LGPL (which forces redistributable applications to
>>> use shared version), and the speed impact. Well, latter isn't a such
>>> big thing here IMHO, but well, I admit that native win32 threading API
>>> is faster.
>>>
>>> Kai
>>>
>>>
>>> --
>>> | (\_/) This is Bunny. Copy and paste
>>> | (='.'=) Bunny into your signature to help
>>> | (")_(") him gain world domination
>>>
>>
>> I just had a look in <gcc-source-tree>/gcc/gthr-win32.h and see that
>> there's already a pretty ok implementation of the GCC gthread API. There's
>> lots of comments about ugliness and most importantly memory leaks, but now I
>> don't understand something: the API is there (or so it seems), so the only
>> thing standing in the way of mingw std::thread is some confogure script
>> magic?
>>
>
> I'm adding some people from the other thread here, to stay a bit more on
> topic ;)
>
Brand new idea: I define
#define _GLIBCXX_HAS_GTHREADS 1
#define _GLIBCXX_USE_C99_STDINT_TR1 1
This adds thread to std:: and allows me to see what undefined stuff there
is! Perfect, no? I'll keep you guys informed.
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
