On Mon, Jan 17, 2011 at 11:57 AM, Charles Wilson
> On 1/17/2011 1:47 PM, Sameer Pillai wrote:
> > I am new to MSYS / MinGW. We are trying to move to MSYS as part of our
> > Windows development environment.
> > As part of profiling it for speed, I ran the MSYS bash.exe through
> > Quantify. It shows three threads and majority of time in two threads is
> > spent on calls to WaitForSingleObject / WaitForMultipleObjects. We
> > currently use MKS toolkit and the bash.exe runs in one thread and is
> > much faster.
> > What are the extra threads in the MSYS bash doing and are they required.
> > Thanks in advance for your replies and insight.
> One thing you have to realize, is that MSYS is a fork of a very old
> version of cygwin. Since that original cygwin software was not
> developed by "us", very few of "us" know much about the innards of how
> cygwin itself worked -- especially the arcane details surrounding
> process execution and the hoops cygwin (ne' MSYS) jumps thru to make the
> Windows CreateProcess execution model match the semantics of the posix
> fork/exec model.
> I probably know more than most on /this/ list about how cygwin works --
> but even so I have only a cursory understanding. In fact, most of the
> people on the *cygwin* list have probably forgotten how cygwin worked,
> back in 2002 (which is when MSYS was forked).
> So...most folks will simply be guessing. Even me. But, here goes:
> cygwin (ne' msys) has to create (at least) two different threads for
> each process. One is the "signal handling" thread, and the other is the
> main execution thread. So, suppose you have process "A": the signal
> handling thread works by monitoring whether some OTHER cygwin (ne' msys)
> process has sent a "unix" signal to process "A", and if so, it flags a
> condition variable to trigger the main thread to execute the signal
> handling functions that may (or may not) have been registered for the
> specified signal.
> Now, in the case of bash, it monitors for LOTS of signals, but most
> especially the SIGCLD child-has-died signal. So, usually you would
> expect bash's signal-handling thread to sit in a WaitFor*() call, and
> occasionally get a signal of some kind and flag the condvar in the main
> thread. Now, for this to work, the main thread also has to check the
> condvar periodically during execution. This is typically handled in
> cygwin system calls IIRC. So, every so often you'd expect to see the
> main thread call WaitFor*() with 0 wait-time (e.g. poll only, no delay).
> Obviously this is a lot slower than if your bash port simply ignored
> unix signals entirely, and used Windows multi-process synchronization
> primitives directly to handle child-process monitoring, which is what I
> suspect the MKS port of bash does.
> But...cygwin aims to provide not just a unix "shell" environment, but
> also an API environment that closely matches POSIX (and, to a lesser
> degree, linux). So, for full support of the posix signal interface we
> have to pay a price. This is part of it.
> There are many other similar areas where the mapping between a true
> POSIX api and the facilities provided by the w32 api requires
> time-consuming and inefficient workarounds...and which you might avoid
> if you were willing to give up complete POSIX api compliance. Since
> cygwin isn't willing...it is slow.
> Now, newer releases of cygwin have made lots of improvements with
> regards to speed (although the recent 1.7 added additional functionality
> and i18n support that slowed down other areas!). Unfortunately, MSYS
> does not reflect those improvements...it has actually changed only
> slightly from its original 2002 fork.
Thanks a lot for your detailed explanation