Hello Kai and Ruben -
I have a few follow-up questions, below.
On Wed, Oct 13, 2010 at 9:06 AM, Ruben Van Boxem
> 2010/10/13 Kai Tietz <ktietz70@...>
>> 2010/10/13 K. Frank <kfrank29.c@...>:
>> > 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,
>> | (\_/) 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.
Thank you, Kai and Ruben -- any further advice would be appreciated.