[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mingw-users
Subject:    Re: [Mingw-users] bash.exe slow due to WaitForSingleObject calls ?
From:       Sameer Pillai <sgp2660 () gmail ! com>
Date:       2011-01-20 0:26:52
Message-ID: AANLkTikU2hvrN4u65n2CeyA_B16ozJNPbo5Qb8ZA2zt_ () mail ! gmail ! com
[Download RAW message or body]

On Mon, Jan 17, 2011 at 11:57 AM, Charles Wilson
<cwilso11@users.sourceforge.net> wrote:
> 
> 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.
> 
> --
> Chuck
> 

Thanks a lot for your detailed explanation

-sameer

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
MinGW-users mailing list
MinGW-users@lists.sourceforge.net

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may \
cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@lists.sourceforge.net?subject=unsubscribe


[prev in list] [next in list] [prev in thread] [next in thread]