This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [CYGWIN] Re: SIGTERM does not stop backend postgres processes immediately


On Fri, May 18, 2001 at 11:03:47PM +0400, egor duda wrote:
>Friday, 18 May, 2001 Christopher Faylor cgf@redhat.com wrote:
>CF> On Fri, May 18, 2001 at 11:23:30AM -0700, Randall R Schulz wrote:
>>>Here's a snippet from the Linux section 2 manual page:
>>>
>>>...
>>>int  select(int  n,  fd_set  *readfds,  fd_set  *writefds, fd_set 
>>>*exceptfds, struct timeval *timeout));
>>>...
>>>timeout  is  an  upper bound on the amount of time elapsed before select 
>>>returns. It may be zero, causing  select  to return  immediately. 
>>>If  timeout  is  NULL  (no timeout), select can block indefinitely.
>>>...
>>>
>>>Does the indefinite-timeout variant of select exist and work under Cygwin 
>>>(or Windows, as the case may be) compatibly with the Linux API spec?
>
>CF> I was actually wrong about polling in the case of sockets.  You don't
>CF> have to poll but, if you use the current method, you would have to
>CF> create a separate thread.  That's pretty expensive, too.
>
>i was thinking of making this socket-select thread persistent. is it
>worth doing? this'll probably speed select() a bit.

That was the way that it used to be implemented.  When I rewrote select
I always thought that I'd eventually make the threads persistent but
never got around to adding the appropriate events.

I'm not sure how much overhead this is, though.  There is also some
resource overhead with keeping multiple threads around, of course.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]