Re: Does anyone understand terminal job control?
On Sun, Feb 08, 2009 at 07:58:51AM -0500, "Douglas A. Tutty" <dtutty@vianet.ca> was heard to say:
> On Sun, Feb 08, 2009 at 05:52:34PM +1000, Adrian Levi wrote:
> > 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
>
> Is the single process a black box or are you writing it too? If its not
> a black box, can't its reads from the terminal just sit and wait for
> input (or test a semiphor before doing anything with the terminal)?
The part that reads from the terminal is a black box -- it could be
anything invoked by a dpkg maintainer script.
> If it is a black box, what happens if it tries to read from std-in if
> std-in doesn't have anything?
After I sent the mail, I figured out that if it ever *actually* tries
to read from stdin, it gets stopped. The problem is that the program
I was testing with apparently blocks in select() instead of reading
outright, and select() doesn't trigger SIGTTIN; it has to issue a read().
> Perhaps your controller program will have
> to be a filter between the process and the terminal: pipe its std-in an
> std-out to the controller process and the controller process issue the
> appropriate shell start/stop commands as necessary while leaving the
> process in the background the whole time.
I thought about this option, but the problem is detecting when the
subprocess is trying to read (but I don't have anything to give it).
One interesting idea I got from the libc manual (but have yet to follow
up on) is to inject a VDSUSP character into the stream -- apparently
this will suspend the process, but only when the character is actually
read. I vaguely recall having some reason to think it might not work,
but it's worth at least trying. (as it happens, since I control the
terminal, I don't need a man in the middle to do this (I think) -- I
can just ask the terminal to send the character)
Daniel
Reply to: