This is the mail archive of the cygwin-developers@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: Outstanding issues with current DLL?


On Sun, Mar 18, 2001 at 08:36:34PM +0300, Egor Duda wrote:
>Hi!
>
>Sunday, 18 March, 2001 Christopher Faylor cgf@redhat.com wrote:
>
>CF> On Sun, Mar 18, 2001 at 06:09:06PM +0300, Egor Duda wrote:
>>>Sunday, 18 March, 2001 Christopher Faylor cgf@redhat.com wrote:
>>>
>>>CF> On Wed, Mar 14, 2001 at 05:55:37PM -0500, Earnie Boyd wrote:
>>>>>This problem doesn't exist in the 2001-Mar-12 snapshot.  However, I do
>>>>>have an occasional lockup on exit.  The startup of the command window is
>>>>>much faster, I had more that fifty windows open in less than 30 seconds
>>>>>just by clicking on the 
>>>>>Office shortcut icon.
>>>
>>>CF> The only lockup that I saw was when I tried to close the window using
>>>CF> the X in the upper right corner.  When this happens, cygwin seems to
>>>CF> be stuck in a "wait for input from fd 0" loop.
>>>
>>>i   see   it   too.  when  i start bash via rxvt and then type 'ps -l'
>>>bash  it prints that rxvt and bash have different pgid's. so when rxvt
>>>receives WM_CLOSE message and tries to exit, it doesn't send SIGHUP to
>>>bash.  so  bash  doesn't see that signal_arrived, and continue to wait
>>>for input.
>
>CF> Well, bash and ps should have different process groups.
>
>yes. they should. but i wonder whether rxvt and bash should have equal
>process groups or not?

When I try this on linux with xterm, xterm and bash don't have the same
process groups.  I think this makes sense since they are each associated
with a different tty.

>CF>   I'm  surprised  that  rxvt doesn't send something to its running
>CF> processes when it gets a SIGHUP.
>
>CF> Is rxvt ignoring the SIGHUP?  Does anyone know?  I would think that it
>CF> would do *something* on receiving this.
>
>no, it doesn't ignore SIGHUP.  what  it  doesn't do is that it doesn't
>propagate  SIGHUP  to it's children. either when closed via 'X' button
>or via 'kill -HUP <rxvt_pid>'

So, rxvt tries to exit but hangs waiting for bash to go away -- which
it never does?  I would have thought that the closing of the parent
pty would cause bash to disappear.

cgf


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