On Sun, 19 Jan 2003, Christoph Egger wrote: > On Sun, 19 Jan 2003, Jos Hulzink wrote: > > > Hi, > > > > KGI used to set a task to sleep when it was mapped away from a display. > > This didn't work always, and with some help from #kernelnewbies, I came to > > the conclusion that it isn't even what you want. > > > > A task doesn't need to sleep, it only has to stop drawing. I came to a > > very simple, but (imho) ingenious solution: Send the task a signal. When > > reading the docs, I noticed that POSIX even defines a signal specially > > made for this, SIGTTOU. This signal is sent to a background process that > > tries to write to its controlling tty. (*) > > Question: What does happen, when a background running process wanna READ > from its controlling tty? > IMO, a SIGTTIN signal should be send to the tasks, then.
Correct. > > The default behaviour of a process is that it is stopped. This looks a > > little ugly on its controlling text console (You see the same as when > > pressing ^Z), and with a "fg" the task starts writing again (without > > setting the mode back), but it is a start. > > > > LibGGI can catch this signal, and behave like it. It can block all > > drawing (maybe if a program requested a directbuffer, sleeping really is > > the only solution). When LibGGI catches this signal, the "fg" issue is > > over immediately. > > > > I'd like to know whether you like this idea, or I have to find another > > solution. > > Well, signal handling is up to the targets. So the kgi target need to > install signal handlers for SIGTTOU and SIGTTIN. > > The question is, what should the signal handlers should do then. There > must be a way to get informed when the kgi target can continue with > reading/writing to its console. > > I think, the best way is to wait for a second SIGTTOU/SIGTTIN signal, > which informs the kgi target to continue. Wrong. SIGCONT is ment for this. It is sent to the tasks already it seems (for they come up again when they are switched to front). Unchecked though. Jos
