Hi! > > > > > ...after resume. > > > > > > > > This is because of how signal_wake_up() works, I think.. > > > > > > > > > But I think it is right approach. > > > > > > Okay, with the appended patch applied everything seems to work and I don't > > > see any undesirable side-effects. > > > > I promise to try it... tommorow. Looks very good to me. > > Unfortunately there's one problem with it. Well, IIRC it still had the 'bash reports vi stopped twice' problem. > To reproduce it I run "gdb /bin/cat", execute "run" in gdb and press ^Z twice > to stop both processes. Next I suspend and resume and run "fg" to get the gdb > back.and press "Enter" to get the prompt. Then, it turns out that the > terminal echo doesn't work and "Enter" doesn't make it go to the next line. > I can recover from this state by typing "fg+Enter" (with no echo) so that > /bin/cat gets the continuation signal and it restores the terminal settings, > apparently. I wonder if we should start a test suite ;-). > This means, however, that with this patch the behavior of a process (gdb) > after the resume may be different to its normal behavior, which is wrong. Yep. > With my original [1/2] this problem doesn't appear (ie. after the resume gdb > behaves normally). Thus I think that, although this patch is much more > elegant, my original [1/2] is a safer solution, because we can say exactly > what it does. Original 1/2 indeed is 'safer'... but it is also too ugly to live. Getting this to work should not be that hard, and I'd prefer not to add more tricky code to already-tricky process.c. In the meantime, perhaps we want 2/2 merged? That one was safe&obvious. Pavel -- Thanks for all the (sleeping) penguins.