Bordeaux-threads issues
Mark Evenson
evenson at panix.com
Wed Jul 22 19:37:37 UTC 2015
> On Jul 22, 2015, at 13:02, Stas Boukarev <stassats at gmail.com> wrote:
>
> Mark Evenson <evenson at 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 at 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")
>>
>>
>> [1]:
>> https://github.com/sionescu/bordeaux-threads/commit/cd370437503a7afc83e96b09e6a26307420b08e2
> 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.
--
"A screaming comes across the sky. It has happened before but there is nothing
to compare to it now."
More information about the armedbear-devel
mailing list