Re: Build report: Successful build of gcc 4.1.2 on Cygwin (Win XP Pro SP2)

["Aaron W. LaFramboise" <aaronavay62 at aaronwl dot com>]

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.