On Mon, Sep 23, 2013 at 7:53 AM, Thad Guidry <[email protected]> wrote:
> Hi Jason,
>
> Nice work.
>
> Curious, this differs in POSIX, I know, but... How long should CUR wait,
> what if TRY never finishes and wait cannot retrieve the exit status to
> determine normal or abnormal (because of various scenarios) and the
> specified process never terminates ?
>
> } else {
> // I am CUR. I wait for TRY to finish. If TRY succeeds I never wake
> up. If TRY fails, I goto the
> // top of the steady-state loop and try again
> std::run::waitpid(pid);
> printfln!("%d: CUR saw TRY process exit, must have failed. Going to
> top of loop to spawn a new try.",
> getpid() as int);
>
Hi Thad,
Thank you.
The user typing at rustxi can press ctrl-c to interrupt TRY with SIGINT at
any time. This is currently how the prototype rustxi is implemented too
(code updated with ctrl-c handling last night), so you can try it out now
if you'd like. Since TRY doesn't catch SIGINT, by default it dies when the
user presses ctrl-c, then CUR wakes up and forks another TRY. TRY blocks
on reading from the pipe connected to VISOR, so it waits in turn for the
user input that VISOR is also blocked waiting for.
This seems like typical and expected REPL behavior. It would be quite
surprising to have a repl decide to think on its own that it can time-out
an operation, even after days, unless there was an explicit timer/watchdog
configured by the user. Since I tend to do CPU intensive things, my
preference is to have CUR wait forever.
Did you have a use case or situation in mind where you thought CUR should
timeout?
Jason
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
