public inbox for
 help / color / mirror / Atom feed
From: "John E. Bossom" <>
To: Ross Johnson <>
Cc: Martin Lambers <>,
Subject: Re: Pthreads-win32 and static linking
Date: Fri, 23 Jul 2010 12:09:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Thanks, Ross...

The original intent when I first wrote the original library was to
have the pthreads-win32 library be usable for those that also wrote
IIS plugin/dlls ... i.e. Windows creates the thread of execution prior
to calling your own plugin... I wanted to seamlessly plug-into the
already created thread.
(Yes... I'm still lurking around ;^)

John E. Bossom

Quoting Ross Johnson <>:

> Martin Lambers wrote:
>> Hello!
>> The Mingw-cross-env project provides a MinGW cross-compiling environment
>> for POSIX systems. For various reasons, all included libraries are
>> static, including the pthreads-win32 library.
>> This means that all pthreads users need to call
>> pthread_win32_thread_attach_np() and pthread_win32_thread_detach_np() in
>> each thread function.
> Only Windows native threads that call POSIX threads routines. See note below.
>> We would like to avoid patching all libraries that use pthread, and
>> instead change pthreads-win32: instead of using a thread main function
>> given to pthread_create() directly, pthreads-win32 could use an internal
>> wrapper that calls the thread main function and also calls the
>> attach/detach functions if necessary.
> Hi Martin,
> Apologies for the slow response.
> Please try the current pthreads-win32 CVS repository head version.
> Anonymous CVS access instructions are on our web page at
> I've applied most of Ramiro Polla's patches and tested the MinGW32 GCC
> static build across the full test suite. The patches that I've omitted
> are just conditional compiler directives that broke the DLL build and
> did not appear to affect the static build. I've emailed Ramiro
> privately for comment.
> Everyone may like to note:
> It is not necessary to call pthread_win32_thread_*_np() for any threads
> created through pthread_create(). That is only necessary for Windows
> native threads that call POSIX API routines in order to interact with
> POSIX threads and only when statically linked (often only the primary
> Windows thread). That is, pthread_create() already effectively does
> what Martin has suggested. I've updated the README.NONPORTABLE file to
> hopefully make that clearer.
> So with Ramiro's patches most applications should now run unmodified
> when statically linked.
> This otherwise transparent ability for Windows and POSIX threads to
> freely interact (via either API) is an aspect of John Bossom's original
> code that has been deliberately retained throughout the evolution of
> the library.
> Regards.
> Ross

      reply	other threads:[~2010-07-23 12:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-10 19:50 Martin Lambers
2010-05-10 20:03 ` Ramiro Polla
2010-06-20  5:15 ` Ross Johnson
2010-07-23 12:09   ` John E. Bossom [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).