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

[Volker Grabsch]

Dear mingw-cross-env supporters,

I finally found the time to take action on the "Pthreads issue".

That is, many of you reported that their binary was hanging
due to a dead-lock, which was observable in Wine by the following
repeating error message:

    err:ntdll:RtlpWaitForCriticalSection section [...] "?"
    wait timed out in thread [...], blocked by [...], retrying (60 sec)

The following people reported that issue on various libraries:

    Aleksandr Tishin
    "hans"
    Nikos Chantziaras
    Bob Bib
    David Bruce

I think this is fixed by now. So it would be great if you could
check whether your problems are solved in the current development
version of mingw-cross-env:

    http://mingw-cross-env.nongnu.org/#development

Theoretically, there are only 5 libraries left which could
cause that trouble again (see below). But I might have
overlooked something, so please test thoroughly.

Below are some details for those who want to know what exactly
I changed and who want to understand the background.


Greets,

    Volker




Details
=======

The above mentioned dead-lock is caused by the Pthreads-w32
library, which is a very old library and doesn't always work
well. It provides a Pthreads-compatible POSIX layer around
the Win32 threading API.

Note that most packages either don't have threading issues,
or use the Win32 API directly for that task, or use threading
only in test programs we don't build (e.g. libxslt). Either
way, they don't use the Pthreads-w32 wrapper, so they are not
affected at all. That's why the issues did't occur more often.

So let's have a look at the affected packages.

The following packages were easy to switch from Pthreads or
"no threading" to using the win32 API for threading:

    fftw

All other affected packages are "pthreads-only" packages, i.e.
packages which have support for Pthreads, but don't support the
native win32 threading API. In order to avoid the Pthreads-w32
wrapper, we have no choice but to disable threading support in
all these "pthreads-only" libraries.

Note that this is not as bad as it sounds. First, almost all
libraries are at least reentrant, so they are thread safe in
every "normal" application. In the rare case when an application
does share library data structures across threads, its developers
usually take care of locking by themselves, not relying solely on
the thread safety of the library. Second, when a library really
needs threading support, its developers usually invest the time
to provide win32 threading support in addition to Pthreads, or
at least refuse to build without Pthreads.

However, since I could be wrong in that regard, please take
extra care of the following "pthreads-only" packages, which
will be built without threading support from now on: [1]

    freetds, guile, libmikmod, libshout, libxml2,
    sqlite, tiff, vorbis, xerces

In addition, the following "pthreads-only" packages have
already been built without threading support up to now,
so nothing changes for them:

    aubio, cairo, devil, openscenegraph, vmime, xz

If you think that any of the above mentioned packages should be
built with Pthreads, and verified that it doesn't suffer from the
dead-lock bug, please drop me a note. In that case I'll of course
(re-)enable threading support for that package.

Finally, there were packages which refused to build without
Pthreads, so I had to keep them using the Pthreads-w32 library:

    fltk, gd, liblo, plotutils, xine-lib

To be exact, the "fltk" library didn't refuse to build without
threading support, but it is a GUI library, so threading support
is mandatory. Also, "gd" and "plotutils" don't really refuse,
but also don't contain a switch to disable Pthreads support, so
it is enabled in order to ensure a defined behaviour. [2]



[1] For reference, these were disabled in the following changeset:
    http://hg.savannah.gnu.org/hgweb/mingw-cross-env/rev/1d442914ae27

[2] Otherwise, it would depend on mere chance whether a package
    is built with or without pthreads, depending on whether the
    pthreads package was built before or after it.


-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR