use of pthreads-win32 in gnulib?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

use of pthreads-win32 in gnulib?

Bruno Haible
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] http://www.gnu.org/software/gnulib/
[2] http://savannah.gnu.org/projects/gnulib

Reply | Threaded
Open this post in threaded view
|

RE: use of pthreads-win32 in gnulib?

Burkhardt, Glenn
We have an application on MinGW that uses pthreads-win32, and I haven't
had any problems.

I did need to pick up a Posix timer package as well for our application,
since MinGW doesn't have one.  I used the now obsolete LinuxThreads
timers, which make use of pthreads, and it works without problems for
us.  It would be nice if pthreads-win32 would pick this up, since timers
are probably almost always needed if threads are needed.

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Bruno Haible
> Sent: Friday, January 18, 2008 8:27 PM
> To: [hidden email]
> Cc: [hidden email]
> Subject: use of pthreads-win32 in gnulib?
>
> 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] http://www.gnu.org/software/gnulib/
> [2] http://savannah.gnu.org/projects/gnulib
>
>
Reply | Threaded
Open this post in threaded view
|

Re: use of pthreads-win32 in gnulib?

Ross Johnson-2
In reply to this post by Bruno Haible
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):-

ftp://ftp.software.ibm.com/software/rational/docs/v2002_r2/rs_readme.html
http://www.rhichome.bnl.gov/Controls/doc/ClearCaseEnv/2003.06/ccase/doc/legal_information.htm 



and:-

http://www.aptech.com/
The pthreads-win32 copyright is acknowledged under Part 6 - Other
Notices at:-
http://www.aptech.com/support_dwn_loads.htm

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.

Regards.
Ross

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] http://www.gnu.org/software/gnulib/
> [2] http://savannah.gnu.org/projects/gnulib
>
>