A possible bug in scsh-0.6.3 beta 4 and questions.
I was trying a variant of Martin Gasbichler's alarm-handler,
http://www.scsh.net/post/alahandler.html, that delivers values by
continuations instead of placeholders. I should probably think some more
about continuations & threads, but anyway, the procedure seems to kill
scsh on its second call. Try and ,open threads locks, then load the code
below and run, e.g., (foo 1) twice. Scsh will die a slow death
terminating with heap overflow.
;; return the values of THUNK to the success continuation K/SUX if THUNK
;; executes in time. Otherwise call the 0-ary failure continuation K/FAIL.
(define (execute/timeout thunk millis k/sux k/fail)
(let ((done? #f) (lock (make-lock)))
(spawn (lambda ()
(sleep millis)
(obtain-lock lock)
(if (not done?) (k/fail))
(release-lock lock)))
(spawn (lambda ()
(receive tuple (thunk)
(obtain-lock lock)
(set! done? #t)
(release-lock lock)
(apply k/sux tuple))))))
(define (foo millis)
(call-with-current-continuation
(lambda (cc)
(execute/timeout (lambda () (sleep 256) (values 0 1))
millis
cc
(lambda () (cc 'time 'out))))))
By the way, how should the executor set up things so that the thread
running the thunk terminates if the latter is slow? The manual describes
only thread suicide (terminate-current-thread), but this won't work as
long as the thunk is running.
rthappe
|