|
Home > Archive > Unix Programming > April 2006 > fork execve and sched_yield()
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
fork execve and sched_yield()
|
|
| broeks@gmail.com 2006-04-27, 7:55 am |
| I'm building a basic shell for class:
In my current program I fork a new process and call the execve function
given a command tailed with the & character (makes sense). However, I
keep getting output like this:
mainshell> ./shell
myshell> ps
PID TTY TIME CMD
17343 pts/14 00:00:00 bash
19423 pts/14 00:00:00 emacs
21959 pts/14 00:00:00 shell
21961 pts/14 00:00:00 ps
myshell> ps &
myshell> PID TTY TIME CMD
17343 pts/14 00:00:00 bash
19423 pts/14 00:00:00 emacs
21959 pts/14 00:00:00 shell
21962 pts/14 00:00:00 ps
<PROMPT FOR USER INPUT HERE>
the display function for the prompt always beats PS, although logically
it occurs later in the program. I tried to use sched_yield() in various
places (in the child, in the parent) to no avail. Any suggestions?
while()
Display Prompt
if &
fork
execve (ps)
else
fork
execve
wait
| |
| Edward Gregor 2006-04-27, 7:55 am |
| broeks@gmail.com wrote:
> myshell> ps &
> myshell> PID TTY TIME CMD
> 17343 pts/14 00:00:00 bash
> 19423 pts/14 00:00:00 emacs
> 21959 pts/14 00:00:00 shell
> 21962 pts/14 00:00:00 ps
> <PROMPT FOR USER INPUT HERE>
>
> the display function for the prompt always beats PS, although logically
> it occurs later in the program. [...]
If I understand you right, you want the prompt printed
after the output of your command. That would mean your
shell must wait for the program to finish its output,
and if you do that you have lost the point with background
processes with &.
| |
| broeks@gmail.com 2006-04-27, 7:55 am |
| I understand that, however, sched_yield() doesn't wait, it puts
something at the back of the ready queue.
In any case, there must be a way to accomplish this.
| |
| broeks@gmail.com 2006-04-27, 7:55 am |
| Now that I think of it, if I make the background process yield
completely to outputting the prompt, I don't lose my advantage
completely.
The background process can yield (say its really complicated) to
displaying my prompt, and then work while I'm sitting at the machine,
watching the cursor flash and typing things.
Still don't know how to make it work though
| |
| Barry Margolin 2006-04-27, 7:55 am |
| In article <1144801951.921727.225310@u72g2000cwu.googlegroups.com>,
broeks@gmail.com wrote:
> I'm building a basic shell for class:
> In my current program I fork a new process and call the execve function
> given a command tailed with the & character (makes sense). However, I
> keep getting output like this:
>
> mainshell> ./shell
> myshell> ps
> PID TTY TIME CMD
> 17343 pts/14 00:00:00 bash
> 19423 pts/14 00:00:00 emacs
> 21959 pts/14 00:00:00 shell
> 21961 pts/14 00:00:00 ps
> myshell> ps &
> myshell> PID TTY TIME CMD
> 17343 pts/14 00:00:00 bash
> 19423 pts/14 00:00:00 emacs
> 21959 pts/14 00:00:00 shell
> 21962 pts/14 00:00:00 ps
> <PROMPT FOR USER INPUT HERE>
>
> the display function for the prompt always beats PS, although logically
> it occurs later in the program. I tried to use sched_yield() in various
No, logically it occurs at the same time. When you put a program in the
background, it is running concurrently with the parent shell, and you
should expect their outputs to be intermixed in an unpredictable way.
I suspect you'll see exactly the same behavior when using one of the
preexisting shells (I just tried it with bash).
> places (in the child, in the parent) to no avail. Any suggestions?
When execing a new program, you'll often have to wait for parts of the
program to be loaded into memory from disk. While this is happening,
the OS will let other processes run, which includes the shell.
Even if the program is already in memory, execve has lots of work to do
to start up a program. sched_yield allows another process to run, but
just for one quantum, and that's probably not long enough for ps to get
very far. When its quantum runs out, other processes will run. When
the shell's turn comes, it has very little work to do to print a prompt,
so it will probably get it all done within its quantum.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
|
|
|
|
|