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 toooooooo
> 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/)
****

Reply via email to