Re: [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1
От | Corinna Vinschen |
---|---|
Тема | Re: [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1 |
Дата | |
Msg-id | 20010716182727.Y25442@cygbert.vinschen.de обсуждение исходный текст |
Ответ на | Re: [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1 (Jason Tishler <Jason.Tishler@dothill.com>) |
Ответы |
Re: [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1
Re: [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1 |
Список | pgsql-cygwin |
On Mon, Jul 16, 2001 at 11:34:29AM -0400, Jason Tishler wrote: > Corrina, > > On Mon, Jul 16, 2001 at 05:19:08PM +0200, Corinna Vinschen wrote: > > On Mon, Jul 16, 2001 at 10:04:17AM -0400, Jason Tishler wrote: > > > What about trying to tackle this from another point of view? I'm not > > > sure if this is doable or acceptable, but what about adding logic to the > > > Cygwin DLL so that it does not send SIGHUP (to itself) when the process is > > > running under cygrunsrv? > > > > Hmmm, sounds like an ugly hack to me... > > Which is why I couched the above with "acceptable." However, there are > other Unix daemons (e.g., inetd) that will respond to SIGHUP in a similar > manner. Is modifying all of them, instead of just the Cygwin DLL, better? That's not what I meant. I just don't like a solution which checks for a specific situation which might change in future due to reasons we don't know yet. Would perhaps changing the general behaviour of Cygwin help? For example when changing the runlevel on a Linux system is requested, init(8) sends a SIGTERM to processes which aren't defined on the new runlevel. Which is a similar situation, IMO. Perhaps changing Cygwin from sending SIGHUP to sending SIGTERM makes any sense? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin@cygwin.com Red Hat, Inc.
В списке pgsql-cygwin по дате отправления: