Re: wait-for-child-process broken for long running child processes

Taylor R Campbell <[email protected]> Tue, 19 Apr 2011 00:00:26 +0000
Newsgroups gmane.lisp.scheme.scheme48
Message-ID <[email protected]>
   Date: Mon, 18 Apr 2011 18:58:37 -0400
   From: Roderic Morris <[email protected]>

   I've come across a bug in wait-for-child-process in the
   posix-processes package.

This is not surprising...  Handling Unix subprocesses and signals is
amazingly complicated -- even without trying to handle job control.

   Unfortunately, there's a space leak somewhere inside the loop, so
   the problem is even worse and manifests itself in the way i
   described.

Presumably this is because it makes lots of `local references' in the
foreign call, which don't get discarded until the call is done.
Perhaps an easy way around this would be to move the loop into Scheme.

   Second, wait-for-child-process will never return in the long
   running child case, unless some other code has called
   make-signal-queue with sigchld as an argument. os-signal-handler
   isn't called for sigchld unless that happens.

Looks like INITIALIZE-SIGNALS in scheme/posix/signal.scm is missing
(maybe-request-os-signal! (signal SIGCHLD)).

   P.S. Is there a way to disable deadlock detection other than the
   (spawn (lambda ()
              ; Sleep for a year
              (sleep (* 1000 60 60 24 365))))
   hack from the manual? I've never had it be helpful, and it's
   especially annoying when doing any work with subprocesses.

If the deadlock detection thinks waiting for a signal is a deadlock,
that's a bug.  Unfortunately, PLACEHOLDER-VALUE and PIPE-READ! ill
express that you're waiting for a signal.  Perhaps the scheduler needs
a hook by which threads can say `I'm waiting for a signal!'.