Re: [PATCH -mm 1/2]: PM: Fix handling of stopped tasks

["Rafael J. Wysocki" <rjw@sisk.pl>]

Hi,

On Friday, 8 December 2006 12:49, Rafael J. Wysocki wrote:
> On Friday, 8 December 2006 12:21, Pavel Machek wrote:
> > 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.
> 
> It doesn't do that for me, but ...
> 
> > > 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.
> 
> Well, I don't agree with that. :-)
> 
> > Getting this to work should not be that hard,
> 
> But it would involve messing up with the scheduler, no?
> 
> > and I'd prefer not to add more tricky code to already-tricky process.c.

BTW, I think the alternative is even more tricky than [1/2] itself, although
the trickiness is not clearly visible in this case.

Greetings,
Rafael


-- 
If you don't have the time to read,
you don't have the time or the tools to write.
		- Stephen King

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV