dce@mips.COM (David Elliott) (07/21/88)
A few years ago, I worked on an Apollo and used csh. After a
while, someone showed me a way to tell csh to disable job
control, which significantly sped up job execution.
Can someone out there refresh my memory on what this command
is?
Also, while I'm at it, does anyone have a program for changing
the color map on the fly? I wrote one once, but it had a bad
habit of crashing the system.
--
David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dcerees@A.CC.UMICH.EDU (Jim Rees) (07/22/88)
A few years ago, I worked on an Apollo and used csh. After a
while, someone showed me a way to tell csh to disable job
control, which significantly sped up job execution.
Can someone out there refresh my memory on what this command
is?
You set the environment variable INPROCESS to "true". But it won't
buy you as much now as it did in the good old days, when vfork was
much slower than it is now. Personally, I wouldn't bother. You
run into other problems running inprocess. It's not worth it.
At sr10, it's a no-op, since most everything runs extra-process.
The one exception is if you run a csh directly from process 1
(the boot shell). It won't work if you aren't running inprocess,
because the streams don't get connected right. But you shouldn't
ever have to do this.
Also, while I'm at it, does anyone have a program for changing
the color map on the fly? I wrote one once, but it had a bad
habit of crashing the system.
I have one, but unfortunately don't have the source for it. I
think I can send it if you really want.
-------benoni@ssc-vax.UUCP (Charles L Ditzel) (07/22/88)
in article <2634@quacky.mips.COM>, dce@mips.COM (David Elliott) says: > Also, while I'm at it, does anyone have a program for changing > the color map on the fly? I wrote one once, but it had a bad > habit of crashing the system. Why write it...there is an Apollo command <do a shift help> for changing the color map on the fly ...of course it is late at night and I have no apollo in front of me ..and I forgotten the command...something like lcm ...or something like that comes to mind ------------------ Yeah! Where was George?
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/29/88)
In article <2634@quacky.mips.COM> dce@mips.COM (David Elliott) writes: >A few years ago, I worked on an Apollo and used csh. After a >while, someone showed me a way to tell csh to disable job >control, which significantly sped up job execution. I don't know how Apollo implemented it, but on a real UNIX system there should be no difference in job execution caused by whether your shell is supporting job control or not.
rees@MAILGW.CC.UMICH.EDU (Jim Rees) (07/30/88)
I don't know how Apollo implemented it, but on a real UNIX system
there should be no difference in job execution caused by whether
your shell is supporting job control or not.
That's because "real" Unix isn't advanced enough to let you run a
program without spawning a whole new process to run it in. Instead,
it relies on total crocks like vfork() to speed up process creation.
Let's not start a flame war, OK?
-------randy@umn-cs.cs.umn.edu (Randy Orrison) (07/30/88)
Recently gwyn@brl.arpa (Doug Gwyn) wrote: |In article <2634@quacky.mips.COM> dce@mips.COM (David Elliott) writes: |>A few years ago, I worked on an Apollo and used csh. After a |>while, someone showed me a way to tell csh to disable job |>control, which significantly sped up job execution. | |I don't know how Apollo implemented it, but on a real UNIX system |there should be no difference in job execution caused by whether |your shell is supporting job control or not. On the Apollos, due to high overhead of fork(), you can tell the shells to not fork when they exec() other processes (don't ask me how the shell gets back). In csh/BSD you can do 'set inprocess' to get this behavior. The default behavior is normal. Remember, Apollos don't run UNIX(tm) or even Unix(which we all know and love), they run AEGIS(which has everyone confused). -randy -- Randy Orrison, Chemical Computer Thinking Battery -- randy@cctb.mn.org randy@ux.acss.umn.edu {bungia, uunet!hi-csc, rutgers, sun}!umn-cs!randy "You're only human, what can you do? It'll soon be over..."
gwyn@BRL.MIL (Doug Gwyn, VLD/VMB) (07/30/88)
Excuse me, but whatever your model of a "process" (or a "job", represented in UNIX by a shared process group ID), the additional control required for a job control shell should not add noticeable overhead. The only time different behavior is required is when a job control-related interrupt is generated (usually by a keypress); plus when a controlled process is spawned there is a tiny amount of extra bookkeeping in the shell. The original comment was that job control on the Apollo caused unacceptable EXECUTION overhead, which is hard to justify given that the CPU cycles and system services should be virtually unaffected by the requirements of job control. This was not meant to start a flame war. I still don't know why job control would add noticeable execution overhead on an Apollo, if in fact it does.
rees@MAILGW.CC.UMICH.EDU (Jim Rees) (07/30/88)
This was not meant to start a flame war. I still don't know why
job control would add noticeable execution overhead on an Apollo,
if in fact it does.
It doesn't. It used to several years ago, which is what the original
message said. But it certainly doesn't any more.
-------benoni@ssc-vax.UUCP (Charles L Ditzel) (07/31/88)
in article <8807291748.AA01877@a.cc.umich.edu>, rees@MAILGW.CC.UMICH.EDU (Jim Rees) says:
-
-
- I don't know how Apollo implemented it, but on a real UNIX system
- there should be no difference in job execution caused by whether
- your shell is supporting job control or not.
-
- That's because "real" Unix isn't advanced enough to let you run a
- program without spawning a whole new process to run it in. Instead,
- it relies on total crocks like vfork() to speed up process creation.
-
- Let's not start a flame war, OK?
Yeah AND real Unix supports process protection unlike Apollo (again pick
any pre-SR10) Unix...i.e. if i am anybody i can kill a root process anywhere
on my Apollo network...incidentally it would be interesting to know if
Apollo's job execution and process protection change with SR10. Hopefully
Apollo Unix will become "advanced" enough to protect processes in the same
way they faithfully protect files. :-)
SR10 will hopefully correct some of the deficiencies that Apollo I'm sure
is tired of hearing about.
------------------------
My Opinions are my own.bts@sas.UUCP (Brian T. Schellenberger) (08/06/88)
[Can't get EMail your way] No, no. The extra overhead was for forking off a new process (which makes job control possible) as opposed to running the program in the shell's own address space. -- --Brian, __________________________________________________ the man from |Brian T. Schellenberger ...!mcnc!rti!sas!bts Babble-On |104 Willoughby Lane work: (919) 467-8000 x7783 ____________________________|Cary, NC 27513 home: (919) 469-9389