[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] Signal woes.
From: |
felix winkelmann |
Subject: |
Re: [Chicken-users] Signal woes. |
Date: |
Sun, 22 Jul 2007 13:39:10 +0200 |
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