I've been building a system that runs (without a tty, if that makes a difference) in the background on a Linux system, and which, in turn runs a series of processes. It's in a fairly normal shell script pipeline and exists for the purpose of multi-threading this one step of the pipeline.

All seems to be well running interactively. However, when the process runs as a gsi-script, it blocks inside ##thread-sleep! in ##process- status. The final result is the script running at 100% of the CPU (polling the port, seemingly) with a dangling child process, which has already exitted (exat?) and is now a zombie.

It seems as though once this happens, each remaining open-process port will block until the full timeout of process-status is reached.

the most relevant functions are here:

(define (throw-shell-error port timeout) (or (zero? (process-status port timeout 100)) (error "fg command failed")) (close-port port))

(define (bg cmd . arguments) (open-process (list path: cmd arguments: arguments)))

(define (fg cmd . arguments) (let ((proc (open-process (list path: cmd arguments: arguments)))) (throw-shell-error proc *join-timeout*)))

I am running these commands purely for side-effects, and not reading from or writing to their ports.

The problem appears to have something to do with load -- I can run a large number of low impact commands, and a much smaller number of "convert" (from the ImageMagick tools) commands before the zombie processes begin to block my execution.

So, as I'm investigating: am I using these commands in the fashion intended by the author? I believe that they are correct in the sense of indicating the programs I mean to run, but am I misusing the port metaphor in some fashion? Any help would be appreciated.

For a bit I had each process represented by a gambit thread, but I'm currently just mapping over collections of ports.

Gambit v4.0.0, Linux 2.6.17.3 running under gsi-script, same behavior with and without -:d. I haven't used other options to gsi-script.