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
If you wish to do it in a reasonably non-messy way, you'd need to
figure out how to chunk your task into pieces that don't block a
thread (or better said, only would block at their last operation),
replace the blocking operations with asynchronous non-blocking
equivalents and have some
Attila Szegedi a écrit :
If you wish to do it in a reasonably non-messy way, you'd need to
figure out how to chunk your task into pieces that don't block a
thread (or better said, only would block at their last operation),
replace the blocking operations with asynchronous non-blocking
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