On Sun, Jul 22, 2007 at 01:39:10PM +0200, felix winkelmann wrote: > On 7/21/07, Robin Lee Powell <[EMAIL PROTECTED]> wrote: > >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.
Can you expand on this a bit? > I can't think of anything besides running a second (native) > thread, if you're into that sort of thing... I haven't the slightest idea how to do that in Chicken. I'd love to, if I could. > Or splitting the application into multiple processes (say, one for > UI/status display and one for the guts). The problem is that the two processes would have to share CDK/curses pointers, like to the curses main window, which I doubt is even possible, and certainly sounds like a bad idea. Having all the UI bits in one place wouldn't solve the problem at all: I'd need to have the user UI bits in one process and the status update UI bits in another, because the user UI bits stop on wgetch most of the time. -Robin -- http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/ Reason #237 To Learn Lojban: "Homonyms: Their Grate!" Proud Supporter of the Singularity Institute - http://singinst.org/ _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
