Re: [Chicken-users] Signal woes.

[felix winkelmann]

On 7/21/07, Robin Lee Powell <address@hidden> wrote:
> I have an app that uses a couple of C libraries.  The general
> problem I'm trying to solve is providing status updates to the user
> in a timely fashion (ideally, about 750ms).
>
> I've tried two approaches, both of which have failed:
>
> 1.  set-signal-handler!.  This just doesn't work at all, because my
> program spends most of its time in one of the C libraries running
> wgetch (the ncurses call), which apparently counts as I/O, which
> apparently stops Chicken from servicing the interrupt.  It simply
> doesn't get serviced until I interact with the program.  Also, it
> can't go sub-second times.

The inerrupt gets detected, but the handler will be called when
the next heap-check takes place (otherwise the code executing
in the handler might run in an inconsistent state).

> 2.  A grotesque hack using foreign code and setitimer and such.  You
> can find this hack at http://paste.lisp.org/display/44881.  The
> problem here is that if the interrupt kicks off when the program is
> busy, the whole program hangs with 100% CPU usage.  I suspect, but
> cannot confirm, that this only happens when the code is in one of
> the C libraries at the time.  Wrapping busy bits of the code in
> (set-signal-handler! signal/alrm #f) / (set-signal-handler!
> signal/alrm actual-call) seems to "solve" the problem, but that's an
> unfortunate solution at best.

uh oh - running Scheme callbacks in interrupt handlers is dangerous:
the set of libc functions that may be called inside them is restricted,
and this is likely to highly risky.

I can't think of anything besides running a second (native) thread,
if you're into that sort of thing... Or splitting the application into multiple
processes (say, one for UI/status display and one for the guts).


cheers,
felix