job control, scheduling, and signals

[Ozan Yigit]

In article <205 at desint.UUCP> geoff at desint.UUCP (Geoff Kuenning) writes:
>.....
>this statement was made in the context of a discussion that explicitly
>separates the decision to "prevent this job from proceeding" from the
>decision to "return the interactive user to the command interpreter
>or to a different previously-active process".  Indeed, these are two
>different functionalities, and there is no reason to lump them together
>as in BSD just because "stopping a job" (as a scheduling decision) is
>a necessary prerequisite to "returning the user to the command
>interpreter".
>

	You make it sound like the only way to stop a process from
	proceeding is to hit ^Z in csh !! The stopping facility, as a
	general operating system facility is there, (SIGSTOP, SIGCONT, 
	SIGTSTP..) and csh happens to use it. I do not see why it should 
	not make use of the facility, given that it is so handy.

	With regards to not returning the user to the command inter-
	preter, what else there to do ?? Since the process is just
	a CHILD, it sounds silly to stop it, and let it hanging to
	the terminal, and sit there.
 

>
>Nobody denies that need;  I just pointed out that BSD lumped the
>implementation together with a piece of the scheduler in an extremely
>inelegant fashion...  
>
	What would be a more *elegant* way ??? It is a general
	facility within the system, and usable from within csh
	with a single keystroke !! [Wait till I get key mappings
	into csh.. than you can use your favorite emacs binding
	for the same purpose :-)]

oZ
-- 

Usenet: [decvax|allegra|linus|ihnp4]!utzoo!yetti!oz
Bitnet: oz@[yusol|yuyetti]
	Join USAGUR [USers AGainst Un*x Retrofitting]
	and support GNU	[the alternative].