Clarification on process restrictions.

[c***@CSIC.UMD.EDU]

So from what I understand children of background processes aren't
allowed to read input from the keyboard.

Dr. Hicks also said that background processes can spawn foreground
processes which also should not be able to read input from the
keyboard.

What should happen in this case:

Shell spawns a background process which spawns a foreground
process A which spawns another foreground process B

Foreground process A should not have Input enabled, is the same
true for foreground process B?

In general, are any children of background processes regardless of
how far you get in levels (grandchildren, great grandchildren etc)
and regardless of foreground/background status supposed to have
their Input Disabled? (This doesn't make sense in an OS but from
the project description and what I heard from Dr. Hicks it's what
the project wants)

[Saurabh Srivastava]

| So from what I understand children of background processes aren't
| allowed to read input from the keyboard.
|
| Dr. Hicks also said that background processes can spawn foreground
| processes which also should not be able to read input from the
| keyboard.

when we say that a background process X spawns a foreground process Y,
what we mean is that X has not explicitly requested for Y to be a
background process (by putting a & or by some other means). So it
certainly makes sense that every descendant of X (which is a bg process)
not be allowed access to input, irrespective of its bg/fg status while
spawning.


|
| What should happen in this case:
|
| Shell spawns a background process which spawns a foreground
| process A which spawns another foreground process B
|
| Foreground process A should not have Input enabled, is the same
| true for foreground process B?
|
| In general, are any children of background processes regardless of
| how far you get in levels (grandchildren, great grandchildren etc)
| and regardless of foreground/background status supposed to have
| their Input Disabled? (This doesn't make sense in an OS but from
| the project description and what I heard from Dr. Hicks it's what
| the project wants)
|


yes, all descendants should have their input disabled.

And this certainly makes sense in a general OS scenario. Would you expect
a process that you start of in the bg, lets say a sendmail program, to
suddenly spawn a fg bash shell and grab your keyboard focus!!?? NO, that
shouldnt be the case. the shell should also have its input disabled.

[c***@CSIC.UMD.EDU]

"And this certainly makes sense in a general OS scenario. Would you expect
a process that you start of in the bg, lets say a sendmail program, to
suddenly spawn a fg bash shell and grab your keyboard focus!!?? NO, that
shouldnt be the case. the shell should also have its input disabled."

Actually yes, I believe background process should be able to open up foreground
processes that allow Input acquisition. How else would you be able to run emacs
blah & in the background and have it open a foreground window where you can have
all I/O enabled while not hogging up that shell?

It would also be useful to have a background process running and checking for
certain conditions (has a certain program been run, do I detect some virus) and
then open up a foreground process that asks the user what he wants to do about it.

But as far as the project1 stuff it doesn't really matter as long as it's clear to
everyone what the spec means.

[Saurabh Srivastava]

| Actually yes, I believe background process should be able to open up
| foreground processes that allow Input acquisition. How else would you
| be able to run emacs blah & in the background and have it open a
| foreground window where you can have all I/O enabled while not hogging
| up that shell?

I should have mentioned that I was excluding the operation of windowing
systems out of my discussion. gui threads, application threads
registering for input and window focus redirection etc are things that
would significantly complicate the discussion given that we dont have a
graphical system in the first place.

i was drawing the parallel to lets say a linux system without X: just the
virtual console for eg. probably my statements make more sense then.

| But as far as the project1 stuff it doesn't really matter as long as
| it's clear to everyone what the spec means.

Ya, as far the project is concerned, a backgrounded processes' descendants
dont get access to input.