www.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1998/08/03/08:30:32

From: cgf AT cygnus DOT com (Christopher Faylor)
Subject: Re: Thread created for select call!
3 Aug 1998 08:30:32 -0700 :
Message-ID: <19980803104326.I23956.cygnus.cygwin32.developers@cygnus.com>
References: <3 DOT 0 DOT 3 DOT 32 DOT 19980803135519 DOT 00a9e590 AT exchange DOT parallax DOT co DOT uk>
Mime-Version: 1.0
To: Andy Piper <andyp AT parallax DOT co DOT uk>, cygwin32-developers AT cygnus DOT com

On Mon, Aug 03, 1998 at 03:33:56PM +0100, Andy Piper wrote:
>At 10:24 03/08/98 -0400, Christopher Faylor wrote:
>>I asked for feedback on this feature when I changed select in the last
>>developers' snapshort.  There was no dissent, so I put this in.  One
>>of the reasons for doing so was to prepare the way for a thread safe
>>version of select.
>
>I'm not against the intent, just the implementation as it stands - select()
>needs to be fast IMHO to be of any use. Any optimisations that you can
>think of would be excellent. For instance thread pooling etc. I also think
>that select() si too heavyweight the way it creates all these objects and
>frees them for every call. select() is likely to be called with the same
>arguments very frequently and this could potentially be capitalised upon.

I've rewritten select from scratch recently, so all of those mallocs/frees
are gone.  Now there are new ones, but hopefully there are fewer.

It still uses thread destruction as a method for determining when a handle
has become "signalled", but it would be easy to change this behavior.  I
wrote select with that possibility in mind, in fact.

This version stands a chance of being in the next public net release.  If
there is a great hue and cry, I'll change it to use events as signallers
and try to keep the thread around if possible.  The bookkeeping for doing
this kind of thing gets hairy when you have to think about using select
from multiple threads, however.

>>You may be seeing a handle leak, however.  I forgot to close the thread
>>handles after they started.  If you have the sources, the fix is simple.
>>Just add CloseHandles to the appropriate cleanup_* routines in select.cc.
>
>Yes I have seen this also:). XEmacs consumes about 20,000 handles after a
>couple of hours.

-- 
cgf AT cygnus DOT com             "Everything has a boolean value, if you stand
http://www.cygnus.com/      far enough away from it."  -- Galena Alyson Canada

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019