On Thu, Nov 03, 2005 at 12:00:59AM +0100, Petr Baudis wrote:
> Yes, I've noticed that as well on newer systems, it would be nice to
> have this fixed. :-)
>
> It is pretty strange, but one workaround is to after unsuccessful resume
> suspend it again and 'fg' right away - it resumes properly the second
> time, at least here.
>
>
I had a look of the source code, the following is quite interesting.
--begin--
#if defined(SIGTSTP) || defined(SIGTTIN)
static void
sig_tstp(struct terminal *term)
{
#ifdef SIGSTOP
pid_t pid = getpid();
block_itrm(0);
#if defined (SIGCONT) && defined(SIGTTOU)
if (!fork()) {
sleep(1);
kill(pid, SIGCONT);
exit(0);
}
#endif
raise(SIGSTOP);
#endif
}
#endif
--end--
What you press ctrl-z to stop it, elinks catches the SIGTSTP signal,
before it sends itself a SIGSTOP signal, it arranges a child process to
send itself a SIGCONT after 1 second.
That's it, when you think elinks is stopped, it is actually running in
the background after only 1 second of stop. This is shown by the "jobs"
command. That's why you can "fg" it right away (in less than 1 second)
when you suspend it again. A sure way to bring it back is to send the
job a SIGSTOP, which it cannot catch.
Why elinks behaves this way is beyond me. Actually there is similar
code in links package as well. Yes, current links package has the same
problem.
Regards,
Qingning
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
