Re: Piping
On Wed, 1 Dec 1999, Adriano Camargo Rodrigues da Cunha wrote:
If you think that spawning many processes for a pipe is a waste of resources
on low-end systems like MSX you should use the temporary file approach, just
like MSXDOS and MS-DOS do.
Yeah, I could, but it's not the right way (and it's t
dirty...), since the pipe() system call exists in UZIX kernel.
For a unix system like uzix, the MS-DOS method is totally useless, indeed.
Last night I tried my first implementation of pipes in sash (UZIX
default shell). I tried only with one pipe.
My algorithm is:
1. put arguments from prompt into char *argv[]
2. check for the pipe symbol ("|")
3. if not found pipe symbol, run as a single executable file
4. pipe(pipe_fd) (result: pipe_fd[0]=read, pipe_fd[1]=write)
5. first fork:
close(pipe_fd[0])
close(1)
dup2(pipe_fd[1], 1)
argv = all arguments before the pipe symbol
execute(argv[0])
6. second fork:
close(pipe_fd[1])
close(0)
dup2(pipe_fd[0], 0)
argv = all arguments after the pipe symbol
execute(argv[0])
7. [wait for all processes to terminate? only last one?]
7. return to prompt
This sounds ok. I presume that process 1 and process 2 are running
simultaniously and are put to sleep when they ask for data that isn't
there yet? If not, that is a problem.
Well, it works for the cat/more pair. Doing a cat fudeba.txt |
more works. But it doesn't work for the ls/more pair. System hangs after
displaying the last file in directory (NOTE: system doesn't crash, just
all processes goes to sleep mode).
Did you think of sending a wake-up signal to the process waiting for data
when there is put data in the buffer after is was empty?
Another question is: shouldn't shell wait for all processes to
terminate? Or just for the last process?
I should say both, since the first can still receive input when the last
died. But most of the time it doesn't matter, since when the last process
dies, the first will recieve a "broken pipe" signal for any output it
sends.
By the way, the pipe() syscall implementation is (well, seems to
be) right, since 'man' works (and it uses a pipe to 'more' to display
manual pages).
It sounds like the process isn't awakened. If that is so, only the pipes
that do not block the second process work. So if the data flow is not
enough, it doesn't work.
Bye,
shevek
/***Use gcc to compile***Don't mind the warning/
int*a,k ,v[9];int*main (){int i,j,s=1, x,z ,c[
]={1,4,7,4,3,4,5,4 ,1,1,1 ,2,
3,3,3,4};for(i=0;( i++9) !k
;s=-s){k=0;scanf("%d",z);v [--z ]=s;for(j=0;j
8; j++){z=v[ c[j ]];k|=z==v [c[
j]- c[j+8]]( z(v[ c[j]+c [j+
8]]==z));;;}}printf(" %d won\n",- s*k );}
/***Tic-tac-toe.use 1-9 to play/
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Piping
Shevek,
7. [wait for all processes to terminate? only last one?]
I tested yesterday. Waiting for all the process to terminate
doesn't hangs system anymore. :)
BUT: by an unknown reason, the flushing of the pipe is not correct
yet. The error seems to be in my algorithm, since 'man' (that make a
pipe to 'more') works perfectly... Maybe I forgot something in the
algorithm?
This sounds ok. I presume that process 1 and process 2 are running
simultaniously
Right.
and are put to sleep when they ask for data that isn't
there yet? If not, that is a problem.
It seemed that second process (reader) was waiting for data
forever... Process 1 (writer) allways have the data (since it reads data
from disk).
Did you think of sending a wake-up signal to the process waiting for data
when there is put data in the buffer after is was empty?
It is done.
Another question is: shouldn't shell wait for all processes to
terminate? Or just for the last process?
I should say both
That's what I did yesterday. After the forks, I put a
for (i=0; i2; i++) {
if ((wait(status)==pid1) close(pipe_fd[0]);
else close(pipe_fd[1]);
}
since the first can still receive input when the last
died. But most of the time it doesn't matter, since when the last process
dies, the first will recieve a "broken pipe" signal for any output it
sends.
I thought that "broken pipe" was an error code set by kernel when
it tries to write to a pipe that has no readers... Interesting... I'll
take a look...
Thanks for you reply, Shevek!
Adriano Camargo Rodrigues da Cunha ([EMAIL PROTECTED])
Engenharia de Computacao - UNICAMP
http://www.adrpage.cjb.net http://if.you.dont.like.msx.usuck.com
* Runtime Error 6D at 417A:32CF: Incompetent User. *
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Piping
Adriano Camargo Rodrigues da Cunha wrote: I thought that "broken pipe" was an error code set by kernel when it tries to write to a pipe that has no readers... Interesting... I'll take a look... In the case of a named-pipe (a fifo-special-file-thing) the writer just goes to sleep, and will never get a broken pipe error. Don't confuse the code for both different types of pipes. David Heremans -- "One difference between SuSE and Red Hat is that the former operates in a country where people don't sue each other over coffee being too hot." Linus Torvalds MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Y2K aftermath on the MSX??
] For instance the dutch echomail system (i.e. sending electronic messages = ] from one BBS to another) will have trouble with the millenium. (the only = ] prog i know so far) Is this problem going to be resolved before the end of the year? Or is everybody using the internet instead of the BBS systems anyway ;-) Kind regards, Alex Wulms -- Alex Wulms/XelaSoft - MSX of anders NIX - Linux 4 ever See my homepage for info on the *** XSA *** format http://www.inter.nl.net/users/A.P.Wulms MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Piping
]
] That's what I did yesterday. After the forks, I put a
] for (i=0; i2; i++) {
] if ((wait(status)==pid1) close(pipe_fd[0]);
] else close(pipe_fd[1]);
] }
]
After the two forks, the shell should close both ends of the pipe, before
going into the wait loop. So, your code should become
4. pipe(pipe_fd)
5. in child of first fork: close(pipe_fd[0]),...
6. in child of second fork: close(pipe_fd[1]),...
7. in parent: close(pipe_fd[0]);close(pipe_fd[1]);
8. for (i=0; i2; i++) wait(status);
Otherwise, you keep too many copies of the pipe filehandles open:
pipe_fd[0] is open in child 2 and in parent, should only be open in child 2.
pipe_fd[1] is open in child 1 and in parent, should only be open in child 1.
I think this will solve your problem. If not, you must review the kernel
implementation of the pipe and you must doublecheck if all filehandles for a
terminated process are properly closed by the kernel during the clean-up.
1)
] since the first can still receive input when the last
] died. But most of the time it doesn't matter, since when the last process
] dies, the first will recieve a "broken pipe" signal for any output it
] sends.
]
2)
] I thought that "broken pipe" was an error code set by kernel when
] it tries to write to a pipe that has no readers... Interesting... I'll
] take a look...
Funny, two ways to say the same thing, since you can summarise 1) and 2) as:
1) A process that writes to a closed pipe, gets a "broken pipe" signal (from
the kernel)
2) The kernel sets the "broken pipe" signal, when a process tries to write to
a pipe that has no readers (hence, is closed).
Kind regards,
Alex Wulms
--
Alex Wulms/XelaSoft - MSX of anders NIX - Linux 4 ever
See my homepage for info on the *** XSA *** format
http://www.inter.nl.net/users/A.P.Wulms
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Y2K aftermath on the MSX??
] AFAIK, the clockchip uses BCD for storing its info, so H99 means decimal ] 99, not 155... This is correct. The RTC works with a BCD format. So, the MSX2 hardware has a 2079 problem. After that year we have to fallback to the MSX1, which does not have a hardware clock and can therefore not have a hardware related date problem. I hope I live long enough to be affected by this particular problem... Kind regards, Alex Wulms -- Alex Wulms/XelaSoft - MSX of anders NIX - Linux 4 ever See my homepage for info on the *** XSA *** format http://www.inter.nl.net/users/A.P.Wulms MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
