public inbox for
 help / color / mirror / Atom feed
From: Ross Johnson <>
To: Pthreads-Win32 list <>
Subject: Re: use of pthreads-win32 in gnulib?
Date: Mon, 21 Jan 2008 13:51:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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.

Hi Bruno,

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
Google search):- 

The pthreads-win32 copyright is acknowledged under Part 6 - Other
Notices at:-

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:
> Hi,
> The GNU gnulib project [1][2] 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?
> Regards,
>                      Bruno
> [1]
> [2]

      parent reply	other threads:[~2008-01-21 13:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-19  1:27 Bruno Haible
2008-01-21 13:02 ` Burkhardt, Glenn
2008-01-21 13:51 ` Ross Johnson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).