Re: [Sbcl-devel] stumpwm hangs

[Julian S. <der...@we...>]

"Faré" <fa...@gm...> writes:

>> The usual method of doing this right is to create a pipe which the signal
>> hander writes to in order to wake up the event loop.
>>
> To integrate signal management into the event loop, you can indeed
> either use a pipe that the signal handler will write to, or under a
> recent Linux, block the signal and use a signalfd() that does it all
> for you. (Under BSD or OSX, a kqueue can do the same). Yikes.
>
> I'd rather see that all done in IOLib or some layer independent of the
> Lisp implementation. Especially if there is to be some level of
> portability in the callbacks to be defined when a child dies (or other
> event happens). But better something that works in SBCL now than wait
> for that to happen.

Using a pipe to map the SIGCHLD to something you can attach a fd-handler
seems pretty easy (hacky patch attached), unless I misunderstood
something. The problem is that the attached version of PROCESS-WAIT will
not immediately notice a finished child when it is in
serve-all-events. Making the timeout given to serve-all-events small is
a way to workaround that, but wastes CPU cycles.

The problematic case is only when streams not based on Unix file
descriptors are used to redirect program in- or output and run-program
has to feed pipes. If there were a way to service the fd-handlers of
these pipes while process-wait blocks in wait3/waitpid, there wouldn't
be a problem. But the only way I can think of right now is using
threads...

And I totally agree that using some I/O abstraction library might be a
good idea.

Regards,
-- 
Julian Stecklina

Well, take it from an old hand: the only reason it would be easier to
program in C is that you can't easily express complex problems in C,
so you don't. - Erik Naggum (in comp.lang.lisp)