Huey <huey_jiang@yahoo.com> wrote:[color=blue]
> I encountered a funny thing, and my code schetch as below:[/color]
[color=blue]
> #define READ 0
> #define WRITE 1
> int byteRead, status, pd[2];
> char buff[100];
>
> pipe(pd);
>
> if (fork()) {
> wait(&status);
> byteRead = read(pd[READ], buff, 100);
> buff[byteRead] = '\0';
>
> } else {
> close(WRITE);
> dup(pd[WRITE]);
> execl("./c_executable", argv1, argv2, NULL);
>
> }[/color]
[color=blue]
> This piece of code works very well for years for me. However, when my
> c_executable got slightly heavier work load (a number of hash and
> processing, and tesed thoroghly), it was broken. While I replaced
> c_executable with lighter work load, it worked again. I am puzzled:
> does the fork/wait pair has a timeout that terminates the child
> process of execl()? If not, why a heavier work load in child process
> failed? If yes, how to make the wait() to WAIT longer? If it is not
> the issue of timeout, what is the kicker behind?[/color]
Sorry, but not a single of the functions you're using here is a
standard C function, making the question off-topic for clc. Please
ask this kind of questions e.g. comp.unix.programmer or a similar
group. It would also be reasonable to specify exactly what you
mean by "broken".
<OT>
No, fork()/wait() doesn't have any timeout. But there are some
strange things in your code, like calling close with an argument
of 1 (I guess you mean STDOUT_FILENO) or the arguments you pass to
execl() - is argv1 the name of the program? - etc. You're also mis-
using the pipe as a temporary buffer, which only works as long as
you don't try to write more bytes to it than the pipe length. And
there are several other things that could go wrong under certain
conditions.
</OT>
Regards, Jens
--
\ Jens Thoms Toerring ___
Jens.Toerring@physik.fu-berlin.de
\__________________________
http://www.toerring.de 
