This is the mail archive of the
mailing list for the pthreas-win32 project.
Re: use of pthreads-win32 in gnulib?
- From: Ross Johnson <Ross dot Johnson at homemail dot com dot au>
- To: Pthreads-Win32 list <pthreads-win32 at sourceware dot org>
- Date: Tue, 22 Jan 2008 00:50:18 +1100
- Subject: Re: use of pthreads-win32 in gnulib?
- References: <firstname.lastname@example.org>
I hadn't realised until I saw Glenn Burkhardt's message that the
original question was posted to the list. Technically GNULib is free to
include code from pthreads-win32 and distribute under the LGPL, so I
take Bruno's message as a courtesy call with some questions thrown in.
My reply to Bruno was as follows.
Inclusion in gnulib is ok provided it doesn't impinge on our freedom to
vary the terms of our license in future. E.g. we may elect to change to
a different open source license. I see that the BSD license is listed as
compatible with the GPL, but IBM's CPL and the Apache license, for
example, are not. Is there a reason for that, or is this just an
omission? We have been looking at possibly changing to one of those
licenses. I'm not sure but this may affect the way we include code
contributed by you back to us under the current license.
I use an oldish version of Msys to create pre-built DLLs for
distribution and pthreads-win32 does build cleanly under mingw using a
standard GNUmakefile. I make an effort to resolve all warnings etc. I
also build the library using MSVC (v6) and nmake, so we have some
cross-checking as well.
The library has been used in numerous free and commercial products and
has been built and run on a wide range of architectures from PDAs to SMP
x64 systems, and judging from past bug reports, all parts of the API
that we provide have been exercised in the real world. We maintain a
regression test suite which must pass on both UP and SMP systems before
we release. The library is mature and can now reasonably be considered
to be of commercial/industrial quality.
A few examples of commercial products that use the library (from a
The pthreads-win32 copyright is acknowledged under Part 6 - Other
Google will find many more.
It's apparently being used in the Windows version of Safari. We have
also received numerous queries from applications vendors large and small
who have tested and are wanting to use the library, but have been
constrained by their legal departments because of the license.
We don't just weakly wrap Win32 constructs and give them POSIX names -
we have been very concerned to provide POSIX semantics and compatibility
as far as possible.
We don't provide POSIX signals so some POSIX threads functions that
depend on them are either limited or missing. These and others should be
noted in the COMPLIANCE file.
We rely on a small separately authored DLL to provide full pre-emptive
asynchronous thread cancellation. Pthreads-win32 will build and run
without this DLL but will then only have limited async thread
cancellation, i.e. threads blocked on external events, such as I/O, will
not cancel until those events are received. This DLL was developed
specifically for pthreads-win32 but is retained as a separately LGPLed
library. See our README file for more info.
Bruno Haible wrote:
The GNU gnulib project  provides a portability library for porting
programs written against the POSIX API to all kinds of platforms. One of
these platforms is mingw (native Win32 API).
All reasonable porting targets nowadays implement the POSIX threads API,
except for mingw. (The others that don't are Solaris 2.4 and BeOS. But these
are not reasonable porting targets any more.) Therefore your library would
nicely fit into gnulib.
What gnulib provides so far, relating to multithreading, is only a portable
layer for handling locks (mutexes) and TLS. But generally it's preferrable
to use the POSIX API rather than some other API; this is another reason
why your library is interesting for gnulib.
How well tested is pthreads-win32? Is there a list of packages that uses it?
Can it be built on mingw with pretty clean, standard Makefile infrastructure?
Does building with "gcc -Wall" produce only a small amount of warnings?
If gnulib started to "virtually" include your library (i.e. make it available
in source code when a gnulib user requests the gnulib module 'pthreads'),
would that be OK with you?