Ron Heiby (The Moderator) <unix-request@cbosgd.UUCP> (04/01/85)
Unix Technical Digest Mon, 1 Apr 85 Volume 1 : Issue 37
Today's Topics:
don't do long jumps in signal handlers
I/O redirection to pipes question
Passwd on PC/IX
Printing in signal handlers vs. setting flags.
proper use of su
Q: How to preserve process state across logout/login?
Rear-end processors for VAX
UNIX training, opinions wanted
----------------------------------------------------------------------
Date: 24 Mar 85 12:09:18 GMT
From: donn@utah-cs.UUCP (Donn Seeley)
Subject: don't do long jumps in signal handlers
From: wls@astrovax.UUCP (William L. Sebok)
In my opinion, if [Berkeley] didn't want signals to abort
terminal reads they should have provided an explicit i/o abort
function that could be called from the signal handler.
I wrote such a function and posted it to the net some time ago... It
was a bit ugly but it worked.
I understand that Berkeley may be considering providing a facility for
4.3 BSD that would allow you to specify that a particular signal can
interrupt a slow system call. This might be done by changing the
on_stack member in the sigvec structure to be a generalized flags
variable, and inventing a flag that would tell the system, 'Don't
restart system calls when you see this signal.'
To quote a recent version of the signal.h file at Berkeley,
'isn't compatibility wonderful!'?
--
Donn Seeley University of Utah CS Dept donn@utah-cs.arpa
40 46' 6"N 111 50' 34"W (801) 581-5668 decvax!utah-cs!donn
------------------------------
Date: 29 Mar 85 20:21:29 GMT
From: gsc@druxr.UUCP (CageG)
Subject: I/O redirection to pipes question
What must be done for a process to exec a child with the childs
stdin and stdout redirected to pipes set up by the parent.
One of the restraints is that the redirection must be done in
the parent process (the child is a tool that I don't want to
change the source for). This must be a commonly done thing since
it is what the shell does when pipes are used with process's.
Send any ideas, information, stuff to druxr!gsc
Thanks in advance
Gary Cage
------------------------------
Date: 25 Mar 85 19:17:19 GMT
From: naftoli@aecom.UUCP
Subject: Passwd on PC/IX
> I just noticed that the PC/IX login command will accept
> the superuser passwd as valid for any user.
That is a feature from Interactive and is also available on
their IS/3 system for the 750/780. It's *very* useful.
--
Robert Berlinger
...{philabs,cucard,pegasus,ihnp4,rocky2}!aecom!naftoli
[Ed note: A bug by any other name would smell as well. :-) RWH.]
------------------------------
Date: 26 Mar 85 19:51:32 GMT
From: radford@calgary.UUCP (Radford Neal)
Subject: Printing in signal handlers vs. setting flags.
If you *must* use signals for something other than fatal error handling, then
just setting a flag is usually best. My advice to print an error message
and terminate the program was meant for cases where you are just trying to
provide a more informative error message than the shell would have given
out.
By the way, if setting a flag is best, why not add a new option to "signal"
that specifies a word in memory to be incremented by the kernel when a
signal arrives, as an addition to the current ignore, trap, terminate options.
This avoids the problems of restarting system calls when the flag methodology
is being used.
Radford Neal
The University of Calgary
------------------------------
Date: 28 Mar 85 17:31:34 GMT
From: phil@amdcad.UUCP (Phil Ngai)
Subject: proper use of su
On my 780 running 4.2, I sometimes want cron to execute certain shell
scripts under user ids other than root, such as uucp and news. Sometimes
I can do:
/bin/su news < shell.script
and sometimes I have to do:
echo shell.script | /bin/su news
Could someone explain this? thanks
--
Phil Ngai (408) 749-5720
UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil
ARPA: amdcad!phil@decwrl.ARPA
------------------------------
Date: 26 Mar 85 15:29:14 GMT
From: begeman@mcc-db.UUCP (Michael Begeman)
Subject: Q: How to preserve process state across logout/login?
I use a network analysis program that takes 1.5 HOURS(!) of cpu time
to load and preprocess a very large net. Each of the subsequent
analysis queries take only a few minutes. How can I save the state
of the process before logout and restore it later? I tried core-dumping
it, but couldn't get adb to restart it correctly, and CSH kills any
stopped jobs at logout. Restriction: I can't dink with the source...this
has to be solved externally. Ideas, wiz? Gracias in advance.
--
Michael L. Begeman Microelectronics and Computer Technology Corp
Software Technology Program Austin (where the sun always shines) Texas
{ihnp4, gatech, seismo, noao, ctvax}!ut-sally!mcc-db!begeman
------------------------------
Date: 28 Mar 85 23:29:03 GMT
From: jbn@wdl1.UUCP
Subject: Q: How to preserve process state across logout/login?
Here's a thought:
Write a network daemon. This daemon, when activated, starts up
the giant job, which does the precomputation, after which the daemon waits
for connection requests. When users connect to it, presumably with TELNET,
they can then talk to the giant job via the daemon. The daemon keeps the
giant job waiting for input when there is no traffic, until the daemon gets
some command via a connection telling it to go away.
This is not a trivial job, but shouldn't take more than a few days
to get going for someone who knows 4.2BSD reasonably well.
John Nagle
------------------------------
Date: 28 Mar 85 00:44:28 GMT
From: wcs@ho95b.UUCP (Bill Stewart)
Subject: Rear-end processors for VAX
> we are looking for micros to hook up to the vax for text
> processing type jobs to take some of the loading off of the computers.
> ...ihp4!tellab1!tellab2!smith
> todd smith
We use a Bell-Labs-developed-and-built box called a "PDQ". It's not an
externally-sold product, but it's got a commercial 68000 board living on a
Multibus with 1/2 Meg of memory, no disk, an RS-232 port, and a small
ROM monitor program that lets the host computer download software and
data files. It normally has either nroff or troff living in it, plus
whatever file it's crunching on at the moment. The host software
looks to see if there's a free PDQ, arranges to download n/troff if
needed and transmit the file. If there's no free PDQ it uses "real"
troff instead.
The box costs us about $6K, and a couple of them really improve the
performance of our CPUs (we mostly use VAXen and 3B-20s, and do a lot
of troff.) The box has about half the horsepower of a VAX 11/780,
and minimal operating system software, so you get a lot more
CPU/process on the box than on your 1/nth share of the host.
The real bottleneck is the RS-232 line (wish we could attach it to
Ethernet or a Unibus!), but our printers are attached by RS-232
anyway; you don't lose much for the typical troff-->Imagen jobs.
If you don't want to build your own box and ROM monitor, it shouldn't
be hard to take a commercial supermicro like the AT&T 3B2 or
anybody's 680x0 UNIX box, store a few standard applications on the disk,
and use uux or whatever to submit jobs to it. (Anybody ported troff
to a Fat Mac?)
Bill Stewart, speaking unofficially at AT&T Bell Labs
[Ed note: I have heard of people using AT&T 3B2s for this purpose. RWH.]
------------------------------
Date: 27 Mar 85 17:32:59 GMT
From: ken@elsie.UUCP (Ken E. Brown)
Subject: UNIX training, opinions wanted
I received a catalog of UNIX and C training seminars from
a group called Computer Technology Group, based in Chicago.
If anyone has any experience with their training seminars
I would appreciate opinions as to the quality of the
seminars, the level of the presentation, etc. Please
mail responses to:
...!decvax!allegra!umcp-cs!elsie!ken
Thanks in advance,
Ken Brown
[Ed note: Is this kind of thing appropriate to mod.unix? It is from
the net groups, in this case. RWH]
------------------------------
End of Unix Technical Digest
******************************
--
Ronald W. Heiby / ihnp4!{wnuxa!heiby|wnuxb!netnews}
AT&T Information Systems, Inc.
Lisle, IL (CU-D21)