On Jul 22, 2015, at 13:02, Stas Boukarev stassats@gmail.com wrote:
Mark Evenson evenson@panix.com writes:
On 2015/7/22 12:26, Stelian Ionescu wrote:
On Wed, 2015-07-22 at 08:27 +0200, Mark Evenson wrote:
On 22 Jul 2015, at 02:00, Stelian Ionescu sionescu@cddr.org wrote:
Hi, can somebody take a look at the Bordeaux-threads support for ABCL? The test suite hangs on Travis-CI.org during automatic tests so I guess there's something wrong there. TraviCI runs Ubuntu 12.04 LTS on x86_64. Thanks.
BORDEAUX-THREADS works fine for me.
[…]
Could you please report the values returned by LISP-IMPLEMENTATION-VERSION?
Using [SLEEP with a value 0][1] may mean "sleep for an indefinite period" on certain JVMs, so I'm a little suspicious of this as an optimization. A better implementation would be to just call java.lang.Thread.yield() directly as in:
(java:jstatic "yield" "java.lang.Thread")
Shouldn't ABCL account for that?
Ideally, yes, I would like ABCL to account for this, providing a uniform behavior. But there is no way to know what the semantics of java.lang.Thread.sleep(0) on the underlying JVM will be. I suppose we could do something like spawn a thread, have it Thread.sleep(0) to see whether it returns or not, caching the result. But it would take a bit of work to figure out how to cleanly remove the potentially “stuck” thread situations that I am not really prepared to chase (I don’t have access to a wide variety of JVM implementations to test). And I am a bit leery of spawning threads without users explicitly requesting them, as it seems it bit unexpected.
@Stas: are you proposing that ABCL *always* convert (SLEEP 0) to Thread.yield()?
Another question to consider here would be to determine if users rely on (SLEEP 0) being equivalent to Thread.sleep(0) to the point that changing the semantics would break existing usage for some.
Well reasoned and insightful proposals are solicited.