Re: [OT] Screen (was Affecting Inst. Change)
Ron Johnson <ron.l.johnson@cox.net>:
>
> On 05/11/07 12:49, s. keeling wrote:
> > Ron Johnson <ron.l.johnson@cox.net>:
> >> Yes, but competent OSs have batch queues for running such jobs. Why
> >> Unix has never had such a capability is beyond my understanding.
> >
> > man batch: at, batch, atq, atrm - queue, examine or delete jobs for
> > later execution.
> >
> >> (NO!! cron is *not* an adequate substitute for batch queues!)
> >
> > cron's for regularly repeated jobs. batch and at are for sequential
> > job scheduling.
>
> How do you create more queues than just "b"?
I'm serious: why? There's only so much resources available in a
machine. Do you want a job to complete asap, or do you want a number
of jobs to complete asap? This is the high ground of performance
analysis we're fiddling with here.
> How do you limit the number of batch jobs that can run at any one
> time? (If the "job limit" of a queue is 4 and you submit 20 jobs,
> the first 4 jobs grab the execute slots, and the remaining 16 wait
> until execute slots open up.)
Meaning, you'd prefer that all 16 jobs run concurrently? That sounds
sub-optimal (for most eventual users, at least).
> How do you tell one job to synchronize on another (i.e., sleep until
> the "other" job is complete, and then continue with your own processing.
I never had to deal with that problem, so I don't know. I'd have done
it another way, personally. Note, I'm not suggesting *nix batch queue
management is superior to others out there.
> > I was running simulations with them in OSF/1 batch
> > queues in the early '90s.
>
> DEC OSF/1, you say? I bet that it took queue management concepts
> from OpenVMS.
You wish. No, even then, the *nix-ish side of DEC barely tolerated
the existence of the VMS-ish side, and vice versa. OSF/1 was very
*nix-ish, and tended to avoid doing anything that might brand them as
being of the same ilk as the VMS side.
It was sure fun to watch those Ultras blow the doors off the VMS
machines though. OSF/1 wasn't originally available for non-Ultra
processors.
--
Any technology distinguishable from magic is insufficiently advanced.
(*) http://www.spots.ab.ca/~keeling Linux Counter #80292
- - http://www.faqs.org/rfcs/rfc1855.html Please, don't Cc: me.
Spammers! http://www.spots.ab.ca/~keeling/emails.html
Reply to: