On 7/21/07, Robin Lee Powell <[EMAIL PROTECTED]> 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 _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
