Re: [Mingw-cross-env-list] Solving the Pthreads issue

[Martin Lambers]

On Fri, 07. May 2010, 00:06:14 +0200, Volker Grabsch wrote:
> Dmitry Groshev <address@hidden> schrieb:
> > On Tue, May 4, 2010 at 07:45, Volker Grabsch <address@hidden> wrote:
> > > This is a very interesting work-around. Thanks for sharing!
> > 
> > This isn't a "workaround", but instead *THE* one and only documented
> > way to use pthreads-win32 as a static library. See here:
> > ftp://sourceware.org/pub/pthreads-win32/sources/pthreads-w32-2-8-0-release/README
> > section named "Building the library as a statically linkable library".
> 
> Thanks for pointing this out! That puts a different complexion on
> the issue. It means that we can't expect any library to work with
> static pthreads-win32. So the situation is worse than I initially
> thought, and we need to find a good way to handle it.
> 
> I see the following options:
> 
>     1)  Keep pthreads-win32 static and create compatibility patches for
>         all libraries that use it.
>     
>     2)  Build pthreads-win32 as DLL.

I did not have a look at it, but maybe it would be possible to 
      
      3) Patch pthreads-win32 so that the pthread_win32_thread_*
         functions are not needed anymore.

For example, instead of using a thread main function given to
phtread_create() directly, the library could use an internal wrapper
that calls the thread main function and also calls the attach/detach
functions if necessary.

The pthread_win32_process_* functions would be less critical because
they only have to be added once per main function. One could check
on each function call whether the library was initialized, and if not,
call pthread_win32_process_attach().

I would argue that better compatibility to the POSIX API outweighs
the increased overhead.

Does anyone know pthreads-win32 good enough to see if this would be
possible?

Martin