This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: [CYGWIN] Re: SIGTERM does not stop backend postgres processes immediately
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?
>
>If so, why not use this variant of select? I agree with you, Chris, that
>polling is very much to be avoided, but as work-arounds go, this approach
>might be acceptable to me.
Corinna already supplied a patch to rectify this behavior so this is a non-issue.
To answer your specific question, however, cygwin implements select()
itself. It isn't a Windows function (although it is a winsock
function). To make select interruptible by Cygwin signals, it is
sometimes necessary to use polling.
I was actually wrong about polling in the case of sockets. You don't
have to poll but, if you use the current method, you would have to
create a separate thread. That's pretty expensive, too.
cgf
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple