On 4/10/08, Colin Walters [EMAIL PROTECTED] wrote:
On Apr 9, 7:49 am, easieste [EMAIL PROTECTED] wrote:
Working in Common Lisp on the JVM, I wish to emulate the semantics of
a typical thread library (there is nothing in ANSI about such
interfaces, they vary widely)
(WITH-TIMEOUT
Christian Vest Hansen wrote:
On 4/10/08, Colin Walters [EMAIL PROTECTED] wrote:
Can't you just Thread.interrupt()?
Interrupting a thread does not, to the best of my knowledge, guarentee
that an arbitrary body of code will actually stop running. If the code
does not invoke any method that
It does not interrupt arbitrary code in any way. That would not be
safe,
since locks could be held, resources could be left unresolved, and
so on.
Long story short, checkpointing is the only way, since the target
thread
must willingly give up in order for you to terminate its
On Apr 10, 8:28 am, Christian Vest Hansen [EMAIL PROTECTED]
wrote:
Interrupting a thread does not, to the best of my knowledge, guarentee
that an arbitrary body of code will actually stop running. If the code
does not invoke any method that might throw some InterruptedException,
then the
All this said, I have just spent the past two hours implementing
something very much like this in a Java framework for executing
scripts in an embedded Rhino engine.
The functionality makes these assumptions:
+ scripts are always single-threaded.
+ scripts share no locks or lockable objects
easieste wrote:
Working in Common Lisp on the JVM, I wish to emulate the semantics of
a typical thread library (there is nothing in ANSI about such
interfaces, they vary widely)
(WITH-TIMEOUT timeout REST body)
which runs an arbitrary BODY of code on a new thread until TIMEOUT
seconds
Charles Oliver Nutter wrote:
FWIW, in JRuby we checkpoint, and we hate having to do it. Essentially
we set up heartbeat checks at the same points where normal Ruby calls
into its thread scheduler. That gives us roughly the same granularity of
events, and so we can emulate interruptible
