Christian Jaeger wrote:
Note that pure Scheme-level solutions won't interrupt C code, for that only a real signal can help, so to make it work really well, a two level approach would be useful, first try the scheme level, then after a timeout run kill(2).
Well, I should note that if the C code doesn't set up an own signal handler and act upon receiption of signals in an appropriate way (e.g. by using sigsetjmp upon entry from scheme and longjmp from the signal handler), even kill wouldn't help you (it would just call the scheme signal handler, which just sets up the necessary flags/info which will be checked when the compiled scheme code next polls those flags; if the scheme code doesn't get a chance to run, nothing happens).
(It would be cool if there would be a way to create a jump buffer which can be longjmp'ed to without having to call sigsetjmp (costing about 120 cycles or so) upon each and every entry to C. The jump buffer target could be some smal 'trampoline' code which inspects the current scheme processor state, and then sets up the cpu to continue to run at the right place (by creating a jump buffer holding the correct values of everything), but I'm sure that would be hairy and not very portable. The better solution may be to have a flag for c-lambda to create those (well you could write a macro |c-lambda-with-jmpbuf| of course).)
Christian.