netnews@wnuxb.UUCP (Heiby) (04/28/85)
Unix Technical Digest Sat, 27 Apr 85 Volume 1 : Issue 52
Today's Topics:
Awk
RTS/CTS on DZ-11 boards
Unkillable processes (2 msgs)
Which IPC for passing control?
----------------------------------------------------------------------
Date: Thu, 25 Apr 85 11:44:31 EST
From: Ralph E Droms <ihnp4!purdue!droms>
Subject: Awk
I'm trying to print all the lines of a file between (and including) a line
containing a particular string (say, "xyzzy") and the end of the file. I
haven't been able to find a string pattern that matches EOF, so I'm using
the awk program:
/xyzzy/,NR == 9999
which is not very aesthetic. Anybody know of a better solution?
- Ralph
[Ed note: Maybe ---- sed -n '/xyzzy/,$p' ---- ? RWH. ]
--
Ralph Droms ihnp4!purdue!droms
445 MATH, Dept. of Computer Science droms@purdue.{arpa|csnet}
Purdue University, West Lafayette, IN 47906
------------------------------
Date: 26 Apr 1985 12:44 EST
From: jhc@hou5g.ATT.UUCP (j.h.clark)
Subject: RTS/CTS on DZ-11 boards
I happen to be something of an expert on this, (boast,
boast) so here goes.
There is no way that straight RTS/CTS will work on a DZ-11 -
the pins are not supported. If I remember correctly, RTS is
strapped internally to DTR, and CTS is not connected. We
have a bunch of LAN (Sytek & U/B) boxes hanging off our
VAXen and we do have RTS/CTS flow control set there, but via
a fix:
We have this variety of flow control enabled on the LAN
boxes, but then we have special cables which transfer CTS on
the DCE (LAN box) end into RI on the DTE (VAX) end. The
DZ-11 *does* support this pin. Then we have specially
modified KMC microcode which looks at RI as a flow control
pin. The kicker is that this is all System V, so I don't
know how applicable it is to you. Martin Levy originally
turned us on to this method, and the KMC microcode came from
Indian Hill somewhere.
However...
I can't understand why your VAX is dropping characters,
unless you are doing single character reads from the
application. In this case, bang the read count up to 128 or
more, and fiddle with VTIME (or whatever the equivalent is).
I spent some time writing UART/TTY drivers and all our
download software (for each machine) had to be tuned by
fiddling these parameters. It really works!
Jonathan Clark
ATT ISL Holmdel NJ
[NAC]!hou5g!jhc
[NAC]!mtung!jhc after May 1
------------------------------
Date: Thu, 25 Apr 85 01:07:19 est
From: Chris Torek <seismo!chris@maryland>
Subject: unkillable processes
They are "sleeping" at an uninterruptable wakeup level, waiting for an
event in the kernel that has not yet happened (and probably never will).
Process control in the Unix kernel is quite simple: there is (at most)
one user process running, and a bunch asleep. Whenever the current
process wants to, it "goes to sleep" by calling the sleep() routine,
giving it two parameters: a "wait channel" (usually a memory address,
though this is not strictly necessary), and a priority.
Whenever a resource becomes available (or an "interesting" state
changes, or for some other reason that seemed appropriate to the kernel
coder), the kernel calls the "wakeup" routine to awaken all sleepers
waiting on a particular channel. This is the way that sleepers
normally become active again.
However, in some cases signals should interrupt sleeping processes.
This is controlled by the priority value given to sleep(). If less
than PZERO, the process is involved in something "fast" (e.g., disk
I/O) and should not be bothered; in others (> PZERO) they are doing
something "slow" (e.g., terminal I/O) and the current system call
should be aborted.
Anyway, what this all boils down to is that if you find an unkillable
process, it's probably run into a bug that is preventing or missing
the wakeup() for its wchan (see "ps l"), and whoever wrote that part
of the kernel felt that aborting the system call on a signal was too
drastic, or a mistake, or too hard to catch using setjmp, or something
like that. Some careful adb'ing will usually find the routine that
missed its wakeup call.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@maryland
------------------------------
Date: 26 Apr 85 17:11:20 CST (Fri)
From: ihnp4!trwrb!trwspp!spp2!jhull
Subject: Unkillable processes
I remember the 2nd problem (although it's been years). I think I was
able to kill (some of) them by nice-ing them to get a positive
priority & then killing them. Doesn't work if they are waiting & have
a negative priority level, then you have to re-boot. (That was V6 &
eons ago, so my memory is fuzzy.)
Blessed Be,
Jeff Hull {decvax,hplabs,ihnp4,scdrdcf,ucbvax}
13817 Yukon Ave. trwrb!trwspp!spp2!jhull
Hawthorne, CA 90250 34o3'15" N by 118o14'28" W
------------------------------
Date: Mon, 1 Apr 85 17:51:23 est
From: seismo!hadron!jsdy (Joseph S. D. Yao)
Subject: Which IPC for passing control?
Neither of the traditional UNIX IPC mechanisms that you mention is
very good for real-time work.
The signal is only caught when the process would normally have been
re-scheduled to run, anyway. If the process is waiting interruptably
for an event (e.g., a sleep() or pause(), a read on a terminal line,
or in some other interruptable system call), then the action being
performed is interrupted and the process is set to run again.
Most implementations of pipe write to and read from disk. Unless you
have ML11's or other core or semiconductor pseudo-discs, this will be
slow, relative to a signal. (But see re 4.2BSD, below.)
Fastest, if you have System IV or System V or 4.2 BSD, are the newer
IPC mechanisms. On System IV/V, these are semaphores, shared memory,
and mailboxes. I haven't looked at how they work relative to sched-
uling, so I can't tell you that. I understand, however, that they
were put in to enable real-time work. Under 4.2 BSD, the new IPC
mechanisms include sockets. Sockets are also totally in memory. But
I don't think that yhe asker has 4.2, since pipes under 4.2 are
implemented as sockets.
Some versions of Xenix (3.0+) have shared memory. I have patched
shared memory into binary 8086 Xenix 2.X, on the Altos.
On other systems, I have used signals as perhaps the best way to do
things like what you wanted to. I d i d add another 16 signals on
to PDP-11 UNIX so as not to conflict with existing signals. Since
Version 6.5, signals had been stored as bits in a word, so I made
them bits in a longword ...
Joe Yao hadron!jsdy@seismo.{ARPA,UUCP}
------------------------------
End of Unix Technical Digest
******************************
--
Ronald W. Heiby / netnews@wnuxb.UUCP | unix-request@cbosgd.UUCP
AT&T Information Systems, Inc., Lisle, IL (CU-D21)