From: "Christopher Faylor" <[EMAIL PROTECTED]> > >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? > > Wow. There is really a communication breakdown here. I keep telling > you that it is not possible to do what you want and you keep acting like > I'm making policy decisions which, if only I would relent, would solve > your problems. He's not "receiving" your meaning. Me bad. -- Tim Baker -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple
- Re: SIGTERM does not stop backend postgres processes im... Fred Yankowski
- Re: SIGTERM does not stop backend postgres process... Jason Tishler
- Re: SIGTERM does not stop backend postgres processes im... Fred Yankowski
- Re: SIGTERM does not stop backend postgres process... Christopher Faylor
- Re: SIGTERM does not stop backend postgres pro... Olivier Fambon
- Re: SIGTERM does not stop backend postgres... Christopher Faylor
- Re: SIGTERM does not stop backend postgres pro... Fred Yankowski
- Re: SIGTERM does not stop backend postgres... Christopher Faylor
- Re: SIGTERM does not stop backend post... Fred Yankowski
- Re: SIGTERM does not stop backend... Christopher Faylor
- Re: SIGTERM does not stop backend... Tim Baker
- Re: SIGTERM does not stop backend post... Robert Collins
- Re: SIGTERM does not stop backend... Corinna Vinschen
- Re: SIGTERM does not stop backend... Jason Tishler
- Re: SIGTERM does not stop backend... Fred Yankowski