Mail Archives: cygwin-developers/1998/08/03/08:30:32
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 -