Pthreads-win32 and static linking

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

Pthreads-win32 and static linking

Martin Lambers-2
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.

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.

To avoid the pthread_win32_process_attach() function, pthreads-win32
could check on each function call whether the library was initialized,
and if not, call pthread_win32_process_attach() itself.

This would induce some overhead, but would allow us to use a large
number of existing libraries unchanged.

Before we start to work on a patch, we would like to know if this
approach has a chance to work. Do you know any technical reasons why
this might fail?

Best regards,
Martin
Reply | Threaded
Open this post in threaded view
|

Re: Pthreads-win32 and static linking

Ramiro Polla-3
Hi,

On Mon, May 10, 2010 at 4:50 PM, Martin Lambers <[hidden email]> wrote:

> 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.
>
> 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.
>
> To avoid the pthread_win32_process_attach() function, pthreads-win32
> could check on each function call whether the library was initialized,
> and if not, call pthread_win32_process_attach() itself.
>
> This would induce some overhead, but would allow us to use a large
> number of existing libraries unchanged.
>
> Before we start to work on a patch, we would like to know if this
> approach has a chance to work. Do you know any technical reasons why
> this might fail?
This has been discussed before. Search this list's archive. The
solution I'm currently using is attached (to patch latest CVS). It
removes the false wsock32 dependency, remove the need to define
something before using the static lib (in mingw32) and hints the
linker to automatically initialize the library. The library can be
built/used by both MSVC and GCC.

Ramiro Polla

autostatic.diff (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Pthreads-win32 and static linking

Ross Johnson-2
In reply to this post by Martin Lambers-2
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
http://sourceware.org/pthreads-win32
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 | Threaded
Open this post in threaded view
|

Re: Pthreads-win32 and static linking

John Bossom
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 <[hidden email]>:

> 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
> http://sourceware.org/pthreads-win32
> 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