Potential bug in internal/runtime/ThreadService?

[nick-someone]

jruby/core/src/main/java/org/jruby/internal/runtime/ThreadService.java

Line 292 in 8ea1605

if (rubyThreadMap.size() >= 0) polling = true;

Here, and a bit below, a Map's (a synchronized WeakHashMap) size is checked as being >= 0 to twiddle the state of the polling field.

I'm pretty sure WeakHashMap would never return a size < 0. I haven't fully grasped the rest of the file (should this only be set iff there's more than 1 active thread?), but certainly if (map.size() >= 0) is always going to be true.

[headius]

Yeah seems like this should be > 0.

Luckily, it turns out we don't use the polling field for anything right now. I remember at one point wanting to add this feature, where like MRI we could turn off certain thread events (like kill, raise across threads) when there's only a main thread. Ultimately checking this boolean turns out to be as expensive as polling anyway, so it never went anywhere.

I'll leave the flag, for API and info purposes, but I'll fix it to be > 0.

[headius]

Yeah, this flag was all over the place. I also found the following logic, which seems to disable polling when there's one (or zero?) threads, so this isn't even internally consistent.

I'm removing the field, deprecating everything involving it, and modifying getPolling to use > 1 since that's what this was intended to indicate.

[headius]

Also worth noting that the access to the map is costly (slower thread init/teardown times), non-atomic (so it's only useful for an immediately-stale point-in-time snapshot) and the boolean is also non-atomically updated, so threads can step on each other.

Just a half-baked feature that never landed.

[nick-someone]

Thanks for the fix!