Re: Does anyone understand terminal job control?
On Sun, Feb 08, 2009 at 05:52:34PM +1000, Adrian Levi <adrian.levi@gmail.com> was heard to say:
> 2009/2/8 Daniel Burrows <dburrows@debian.org>:
> > Hello list,
> >
> > I've been banging my head on this one for a while.
> >
> > I have a need to write some code that can manage job control on a
> > terminal. More specifically, I need to run a single process and stuff
> > it into the background at will, so that it gets suspended when it tries
> > to read from the terminal. So, there's a "controller" process and
> > a "subprocess" process.
> >
> > controller ----------> subprocess
> > manages
>
> You cant send the equivalent of ^z then fg to resume?
> AFAIK the process will be suspended until you type bg to run the
> process in the background or fg to bring it back into the foreground.
Well, the issue is that I don't know when to sent the SIGSTOP (that
is, ^Z). :-) I'm trying to do it only when the process wants to read
from the terminal, but allow it to run unmolested otherwise.
Based on some additional tests I ran, it looks like the mechanism
that triggers SIGTTIN only activates when the subprocess actually
invokes the read() system call -- the one I was testing with blocks in
select() until input is available, and that doesn't seem to trigger the
TTIN. (if I type a character while it's "in the background", that does
cause it to suspend)
The use case here is basically that I have a hidden terminal with a
long-running batch process that occasionally prompts for user input,
and I want to detect when it's waiting so I can alert the user. I'm
trying to find a way to get it to emit some sort of signal / event that
the parent process can catch, and I latched onto SIGTTIN as a route to
that. It's looking to me like it might not be possible to implement
what I want through the job control mechanism, although I found some
intriguing notes about VDSUSP yesterday that I haven't followed up on.
Daniel
Reply to: