On Oct 24, 2011, at 17:59 , James Lawrence wrote:
[…]
Thanks for the response.
That seems like a different issue. The purpose is not to guarantee that the thread is destroyed.
The behavior sought is: when the protected form stops executing, run the cleanup forms.
[…]
In my case I am only interested in detecting the termination of a thread without polling. Maybe there is an ABCL-specific way to do that.
THREADS:THREAD-ALIVE-P Function: Boolean predicate whether THREAD is alive.
On Mon, Oct 24, 2011 at 12:23 PM, Mark Evenson evenson.not.org@gmail.com wrote:
On Oct 24, 2011, at 17:59 , James Lawrence wrote:
In my case I am only interested in detecting the termination of a thread without polling. Maybe there is an ABCL-specific way to do that.
THREADS:THREAD-ALIVE-P Function: Boolean predicate whether THREAD is alive.
Well as I mentioned, I am interested a non-polling alternative.
On Oct 24, 2011, at 18:38 , James Lawrence wrote:
On Mon, Oct 24, 2011 at 12:23 PM, Mark Evenson evenson.not.org@gmail.com wrote:
On Oct 24, 2011, at 17:59 , James Lawrence wrote:
In my case I am only interested in detecting the termination of a thread without polling. Maybe there is an ABCL-specific way to do that.
THREADS:THREAD-ALIVE-P Function: Boolean predicate whether THREAD is alive.
Well as I mentioned, I am interested a non-polling alternative.
The [java.util.concurrent][1] package as [thread pool Executors][2] that definitely don't poll, and arguably provide some of the most performant queuing available for the Oracle JVM implementation. At least you need a good reason *not* to use it, as it is thoroughly debugged and tested. Suggest using [JSS][3]
[1]: http://download.oracle.com/javase/6/docs/api/java/util/concurrent/package-su... [2]: http://download.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPool... [3]: http://code.google.com/p/abcl-dynamic-install/wiki/JSS
On Mon, Oct 24, 2011 at 12:59 PM, Mark Evenson evenson.not.org@gmail.com wrote:
The [java.util.concurrent][1] package as [thread pool Executors][2] that definitely don't poll, and arguably provide some of the most performant queuing available for the Oracle JVM implementation. At least you need a good reason *not* to use it, as it is thoroughly debugged and tested. Suggest using [JSS][3]
OK thanks for the info.
Just so I can evaluate my options better -- do you foresee ABCL behaving like the other implementations in the future? That is, executing cleanup forms when the protected form is halted? As I mentioned, this is independent (at least conceptually) of an actual thread death event, which happens at some unspecified point in the future (or not) and is uninteresting (at least to me) as long as the cleanup gets executed.
On Oct 24, 2011, at 23:59 , James Lawrence wrote:
On Mon, Oct 24, 2011 at 12:59 PM, Mark Evenson evenson.not.org@gmail.com wrote:
The [java.util.concurrent][1] package as [thread pool Executors][2] that definitely don't poll, and arguably provide some of the most performant queuing available for the Oracle JVM implementation. At least you need a good reason *not* to use it, as it is thoroughly debugged and tested. Suggest using [JSS][3]
OK thanks for the info.
Just so I can evaluate my options better -- do you foresee ABCL behaving like the other implementations in the future? That is, executing cleanup forms when the protected form is halted? As I mentioned, this is independent (at least conceptually) of an actual thread death event, which happens at some unspecified point in the future (or not) and is uninteresting (at least to me) as long as the cleanup gets executed.
I think Alessio has provided good reasoning for a way forward into a near future where ABCL matches the behavior of other implementations, as I now think my initial analysis (and statements) was (were) a bit uninformed.
If patches were to show up that Did the Right Thing, we would probably immediately incorporate them into trunk. Otherwise, we will open a ticket for this issue, finding resources at some point in the future to perform the necessary cleanup barring any other effects on the implementation that its introduction would produce.
armedbear-devel@common-lisp.net
-
James Lawrence -
Mark Evenson