Stefan Monnier <stefan.monnier_at_epfl.ch> wrote:
> STk> (run-process "ls" :output "tmp")
> #<process PID=4040>
> STk> Bye.
>
> Right after launching "ls", STk quits. If ls is run with ":wait #t", it works
> fine. It feels like the signal send by "ls" when it finishes (SIGCHLD or
> somesuch) is not correctly caught by STk.
I just upgraded to 2.2.0 and the problem is still the same.
STk> (run-process "sleep" "10" :wait #f)
#<process PID=16332>
STk> (run-process "sleep" "30" :wait #t)
#<process PID=16333>
STk> Bye.
What you cannot see on this is that the first process was started at time 0s and
returned immediately (of course), the second process was started at time 5s
and returned at time 10s and STk said "Bye." at time 35s.
Obviously the SIGCHLD signal handler didn't correctly associate the signals with
the processes.
Also, when the last SIGCHLD was received, I don't know what happened in the
sighandler, but the read() call (which was waiting on the user's input) returned
with a count of "-1" which the toplevel loop interpreted as an EOF. This is
why it left.
Looking at the read and wait manpages, it seems the problem is always the same:
when a signal arrives while the program is waiting in "read" or in "wait", the
syscall is returns immediately with some kind of "error" message indicating
that the syscall has been aborted. The problem is that neither for the wait,
not for the read does STk deal with such situations.
Stefan
Received on Fri Aug 18 1995 - 14:18:47 CEST