Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ll-xn!ames!elan!jlo
From: jlo@elan.UUCP (Jeff Lo)
Newsgroups: comp.unix.wizards
Subject: Re: System V job control idea
Message-ID: <165@elan.UUCP>
Date: Tue, 12-May-87 13:34:28 EDT
Article-I.D.: elan.165
Posted: Tue May 12 13:34:28 1987
Date-Received: Fri, 15-May-87 01:04:57 EDT
References: <337@tdi2.UUCP> <757@mcgill-vision.UUCP>
Organization: Elan Computer Group, Palo Alto, CA
Lines: 45
Summary: A limited form of job control can be implemented by ptrace.

In article <757@mcgill-vision.UUCP>, mouse@mcgill-vision.UUCP (der Mouse) writes:
> In article <337@tdi2.UUCP>, brandon@tdi2.UUCP (Brandon Allbery) writes:
> > Recently it occurred to me that there exists a form of simple job
> > control under every version of UNIX since the Seventh Edition (at
> > least).  It's called ptrace().
> 
> A very interesting notion.  Probably worth at least following up
> somewhat.

When I was working at HP, and was using HP-UX, a System V variant, I tried
this idea out. I didn't have time to work out all the bugs, but I could
stop running jobs by starting jobs from a shell with ptrace(). I wuold then
intercept any signals, and restart the process with the same signal unless
it was SIGQUIT. The signal can be found by checking the status from wait().
In this case I would just stop the job. It could then be restarted, ignoring
the signal. In case I really wanted a core dump, which couldn't be generated
by from the keyboard without SIGQUIT, I added a function to the shell which
would restart a stopped job with SIGQUIT. I never had time to really clean
everything up, and now I'm back to a BSD system, so I'll probably never
finish it.

If anyone decides to try this themselves, I'd be interested in seeing how
it works out. Here are some things to watch out for. Just allowing a user
to run processes, stop them, and restart them in the foreground isn't that
hard. If you want to be able to move a job from running in the foreground
to running in the background there are some problems. There are no SIGTTOU
or SIGTTIN signals in SysV. The first one isn't really necessary, not having
it will just allow a background process to write all over the terminal while
something else is running, as with "stty -tostop". However, if a process
tries to read something from the terminal, what happens? Without SIGTTIN to
tell you this is happening, my guess is it will fight with the other
processes reading from the terminal for input. The one way I have thought of
to get around this is to use ptrace() again. Set a breakpoint at _read and
check the stack for file descriptor 0. You will also have to parse the
command line to see if stdin was redirected from somewhere else, and you
still won't know if fd 0 was closed and then reopened to something other than
the terminal. And this much works only if there is a symbol table in the
binary to find the address of _read from. Things like select() may also get
confused. Using ptrace() in this way may also slow down execution a lot.
There is no penalty to just run and intercept signals, but breakpoints may
slow it down considerably.

					Jeff Lo
					Elan Computer Group
					..!{ames,hplabs}!elan!jlo