Hello Kai and Ruben - I have a few follow-up questions, below.
On Wed, Oct 13, 2010 at 9:06 AM, Ruben Van Boxem <[email protected]> wrote: > 2010/10/13 Kai Tietz <[email protected]> >> >> ... >> 2010/10/13 K. Frank <[email protected]>: >> > I haven't the faintest idea about how to integrate this stuff with the >> > mingw proper. >> > One issue (among many) is that I am ill equipped to test on >> > anything other than 64-bit windows 7. >> > ... >> > The gnu sources have a test suite for std::thread: >> > >> > http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/testsuite/30_threads/ >> >> Well, this is the gcc testsuite and it gets regular ran by many >> people. NightStrike even post its results regulary to gcc's ML. >> Is there a practical way to get the experimental code into the hands of people who run the test suite or do other kinds of testing, especially on platforms other than 64-bit windows 7 (and the particular builds of mingw32 and mingw-w64 that I happen to be using)? >> > ... >> Well, license is here the "jumping point". The pthread-win32 project >> is LGPL, which isn't bad, but has some unwanted side-effects to its >> users, as it disallows the use of static libraries in none-GPLed code >> As we - and I assume it is the same for mingw.org - are having the >> goal to provide the base runtime so, that every user can use it >> without any implication due license, we decised to start a new project >> "winpthread" (to be found on our experimental repository tree) having >> a more *free* license, which we will integrate into our base runtime >> after tests are done. When we have achieved this, I plan to change >> gthr-win32 in gcc so, that it can use the pthread layer for Windows >> targets - if available. I'm pretty sure I understand your goal here (although I don't understand all of the details of the licensing issues). As a practical matter as I add the various pieces to get std::thread working with mingw, what sort of licensing issues should I be keeping in mind to help ensure that your goals are met? Is there specific licensing verbiage I should be adding to the code, or is there verbiage I should make a point of avoiding? In very concrete terms, when I modify an existing source file, should I do anything with the existing licensing verbiage? When I create a new source file, what licensing verbiage should I put in it? Should the wording in a .c file be the same as, or different from that in a .h file? >> > ... >> >> Best regards, >> Kai>> >> ... >> | (\_/) This is Bunny. (Hello, Bunny. No world domination for you today.) >> ... > As Frank has done work on implementing via native threads, > perhaps the new winpthread code can be used as a fallback (for pre-Vista > machines) to the native implementation. Yes, that was my thinking too. That was why I tweaked std::thread and gthr-posix.h to get std::thread working with pthreads. (But, absent the new winpthread implementation of pthreads, what I did does nothing to address the pthreads licensing issue.) > How this could be accomplished? > Perhaps through an ifdef for WINNT_VER and apply the relevant code through > that? The rationale behind this would be performance, and that would of > course need to be tested before such a decision is made IMHO > ... In terms of performance, a couple of thoughts: (Note, I haven't done any performance testing -- right now I'm happy if the code looks like it works.) First, I am trying to do something less ambitious than pthreads. Pthreads offers richer functionality than the subset of pthreads (or gthreads, if you will) that is used in the gnu implementation of std::thread. So there is the possibility (but no assurance) that if you are doing less, you can do it more cheaply. Second, you would think that a native implementation would be faster than a non-native implementation. Of course, this depends both on the quality of the underlying windows implementation, and on the quality of the glue that connects std::thread to windows (that is, on the quality of the layer I am trying to write). One last comment on performance: I am trying to put together a native windows implementation of the parts of the gthreads interface that std::thread uses. This does introduce an unavoidable performance penalty relative to a pure native std::thread implementation (i.e., no gthreads layer), at least for thread creation. This is because both std::thread and gthreads have to introduce their own wrapper for the thread-function passed to the new thread. std::thread and gthreads have different thread-function interfaces, and neither matches the native windows interface. On this note, for reasons that may or may not make much sense, I have elected to leave std::thread code essentially unchanged, and support std::thread by implementing the gthreads layer, even at the cost of this performance hit. > ... > Ruben Thank you, Kai and Ruben -- any further advice would be appreciated. K. Frank ------------------------------------------------------------------------------ Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
