This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: [CYGWIN] Re: SIGTERM does not stop backend postgres processes immediately
- To: cygwin-developers at cygwin dot com
- Subject: Re: [CYGWIN] Re: SIGTERM does not stop backend postgres processes immediately
- From: egor duda <deo at logos-m dot ru>
- Date: Fri, 18 May 2001 23:03:47 +0400
- Organization: deo
- References: <3AFF4B61.39A0B754@tpf.co.jp> <20010509094031.A87424@enteract.com><20010509142629.J355@dothill.com> <20010509164926.C3169@redhat.com><3AFF4B61.39A0B754@tpf.co.jp> <20010513231432.A5059@redhat.com><5.1.0.14.2.20010518110716.01b581e8@pop3.cris.com><20010518144119.A8011@redhat.com>
- Reply-To: egor duda <cygwin-developers at cygwin dot com>
Hi!
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.
Egor. mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19