Brian Dessent wrote:
"Aaron W. LaFramboise" wrote:
I don't really see any compelling reason that win32 threads shouldn't
work on Cygwin. As far as I know, nothing about this choice is
ultimately exposed to the user. In fact, Win32 threads are quite likely
to yield superior performance anywhere where it matters.
There is a very compelling reason. If you go creating threads behind
Cygwin's back by calling the Win32 API directly, you will quickly get
very wrong results as you try to use other features of Cygwin. In order
to correctly emulate a posix API under Windows, Cygwin has to handle all
creation and deletion of resources, including threads, and the
corresponding bookkeeping to keep track of them.
The main thing --enable-threads controls is synchronization between
threads, for example, when throwing exceptions. In general, it does not
control how threads are created, which has nothing to do with GCC. (An
exception is ObjC which needs to create a thread for a detach feature.)
Regardless, I'd be surprised if this was an issue, since the Cygwin DLL
receives notification of every thread creation anyway, and can create
any needed per-thread information at that time. CreateThread() works
just fine with Cygwin. In fact, since Cygwin 1.3.13-1 (Oct 2002),
Cygwin has even supported using these threads later pthreads calls.
However, I checked the source, and --enable-threads doesn't really work
in this way anyway. On *-*-cygwin, --enable-threads=win32 is equivalent
to --disable-threads. Similarly, on *-*-mingw32,
--enable-threads==posix won't work. Since most targets only allow a
single thread type, and ignore all others, this option is sort of
misleading, particularly as it doesn't tell you that your selection has
been ignored, and has in fact had the opposite effect from what was
intended.
