Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-developers-owner AT cygwin DOT com
Date: Thu, 1 Aug 2002 12:37:16 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: potential instability in cygwin after my last checkin
Message-ID: <20020801163716.GA20607@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.23.1i

I had a brainstorm for a way to reuse threads in the select() scenario
and have implemented it in the last couple of days.

This required adding some new code for manipulating cygwin-specific
threads and replacing the thread functions in debug.cc with "better"
versions throughout.

I've tested that basic things like ssh and bash work but haven't had a
chance to do more than that yet.  However, I have checked my changes in
since I'm satisfied that they form a good basis for some further changes
that I'm contemplating.  I'm generating a snapshot now so that I can see
how things would work in an official release.

(oops.  snapshot failed.  stupid error...  restarting)

I'm hoping that these changes will eliminate the thread
creation/deletion overhead that has plagued select() since I rewrote it
years ago.

Currently, the code is limited to having select work from only one
thread.  Probably calling select from two threads at the same time would
be ok but more than that would undoubtedly cause bad things to happen
(tm).

For the curious, my changes introduce the concept of a "thread pool"
(radical idea huh?) which cygwin will use as needed.  The threads are
created early in cygwin startup in a suspended state.  Threads in this
pool don't ever actually terminate.  They wait around to be woken up and
call a specified thread function and then suspend themselves again,
waiting for the next request.

What's missing currently is some facility for extending the pool on an
as-needed basis.  I also think I may have added some scheduling
granularity in my use of SuspendThread, too.  I may need to add an event
or something rather than using SuspendThread for synchronization.  IIRC,
MSDN admonishes people not to do that.

So, it's possible that my current implementation is actually slower than
the old one.  I'll check on that in the next couple of days.

Conrad do you have some kind of benchmarking software for sockets that
might use select() by any chance?

cgf