This is the mail archive of the cygwin@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: SIGTERM does not stop backend postgres processes immediately


On Thu, May 10, 2001 at 02:07:21PM -0400, Christopher Faylor wrote:
> What mechanism is this?  You have already demonstrated that you can't
> use Cygwin signals to interrupt a recv.  You seem to be using circular
> reasoning:

There are two 'recv()' APIs involved here:  the Win32/winsock one, and
cygwin_recv() which is exported as recv() by the cygwin DLL.  Let's
call them "recv(win32)" and "recv(cygwin)", respectively.  I haven't
found a way to get an interrupt handler to run while recv(cygwin) is
blocked, apparently because Cygwin code goes out of its way to prevent
exactly that, deferring handler execution until recv(win32) unblocks.
Because of that, I don't know if recv(win32) can be "interrupted" by
calling closesocket().

Doesn't each Cygwin process have at least two threads, a main thread
and an implicit signal-handling thread?  At the least, I do see
internal Cygwin code, such as sig_wait(), running in immediate
response to SIGTERM -- even while recv(win32) is blocked.

> I'll bet the the Open Group would imply that a signal does not close
> a socket if you are blocked in a recv() call, too.

I agree.  My thought was to have the _application_ close the socket
from a signal handler, thereby unblocking both the recv(win32) call
and, as a direct result, the recv(cygwin) call.  If there was some
other way to immediately unblock the recv(win32) call, that would be
preferable.  It seems that WSACancelBlockingCall is no longer
available.

> I don't know why you are getting the impression that I'm passing down
> an edict.

That's not the impression I am getting.

> I'm always open to methods for getting Cygwin to work
> more like UNIX.  I don't see how closing the socket can achieve this
> goal, even if you could make it work.

I don't want Cygwin to close the socket.  What I'm trying to get
working is an existing application, the PostgreSQL "backend" process,
that blocks on recv() and reacts to SIGTERM by immediately cleaning up
and exiting.  I'm looking for some way to do this in Cygwin, and
closing the socket from a signal handler in the application was one
kludge that I was exploring to try to get a similar effect.

I don't think that putting the recv() call in its own thread is an
option in this case, since the PostgreSQL developers are unlikely to
approve that much of a change just to support Cygwin.

If an application signal handler was allowed to run while the process
is blocked on recv(cygwin), at least the application would have some
chance to react to the signal immediately.  In a typical default Unix
situation, I think this would result in the application call to recv()
returning -1 with errno set to EINTR.  It is hard to see how Cygwin
could emulate this in the general case if closing the socket is the
only way to unblock recv(win32).  But what's the harm in allowing
signals to be handled while in recv(cygwin) even if recv(win32)
remains blocked?

-- 
Fred Yankowski           fred@OntoSys.com      tel: +1.630.879.1312
Principal Consultant     www.OntoSys.com       fax: +1.630.879.1370
OntoSys, Inc             38W242 Deerpath Rd, Batavia, IL 60510, USA

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple


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