<fbytez>
For some reason, after forking, if I close stdin — `(close 0)` — the child doesn't function correcting despite not using stdin for anything in the child's code.
<fbytez>
*correctly
<fbytez>
Is there a `task` running on it or something?
<fbytez>
That is, I call `(close 0)` in the child; not the parent.
<abu[7]>
Yes, this is well possible
<abu[7]>
stdin might be implicit
<abu[7]>
Where does the child wait in? 'wait', 'key' etc.?
<abu[7]>
i.e. if the child falls through to the REPL, it calls 'key' (readline) on stdin
<abu[7]>
Also, I think the error handler checks whether stdin is a tty
<fbytez>
Right. I might be falling through somewhere instead of exiting.
<abu[7]>
and drops into an error repl if so, otherwise exits immediately
<fbytez>
Is there any kind of function that basically just yields and just lets the tasks run?
<abu[7]>
yes, 'wait'
<abu[7]>
Normally apps are started with -wait at the end of the command line
<abu[7]>
Without it, the child drops into a REPL
<abu[7]>
which is desired during debugging
<abu[7]>
I start apps in debug mode as
<abu[7]>
$ pil xxx.l -main -go +
<abu[7]>
and on the production server as
<abu[7]>
$ pil xxx.l -main -go -wait
<fbytez>
Yep, that was it, thanks. `(wait)` with no arguments isn't documented, by the way.
<abu[7]>
Well, only indirectly: "When cnt is non-NIL"
<abu[7]>
So NIL waits infinitely
<fbytez>
Yeah, I can see how it's implied but it's definitely not clear to me as currently documented.
<abu[7]>
Agreed. But most example applications document the -wait invocation
seninha has joined #picolisp
rob_w has quit [Remote host closed the connection]
rob_w has joined #picolisp
chexum has quit [Remote host closed the connection]
chexum has joined #picolisp
seninha has quit [Ping timeout: 256 seconds]
beneroth has quit [Ping timeout: 245 seconds]
seninha has joined #picolisp
beneroth has joined #picolisp
rob_w has quit [Read error: Connection reset by peer]
beneroth has quit [Read error: Connection reset by peer]