<headius[m]>
woot, with that tweak we appear to be consistently fastest or matching TR on the unpack scenarios from ahorek
<headius[m]>
and this could get better
<headius[m]>
I aborted my attempt to replace ByteBuffer wrapper with a ByteListCursor that just maintains position, but that would reduce the size of allocated objects quite a bit (ByteBuffer has a half-dozen fields)
<enebo[m]>
headius: looks good and I appreciate that logging. I wonder if we can figure out a reasonable way to test via logging in the future
<headius[m]>
yeah I'd like the logging to be more integral to indy binding as well, so it can't break if someone happens to delete or move a line of code
<headius[m]>
in general I'd like all indy binding to be more declarative than it is now
<headius[m]>
give me a ruling on that second PR too please
<headius[m]>
I've got a thread mutex PR coming shortly that fixes two 9.2.9 issues
KeyJoo has quit [Quit: KeyJoo]
<headius[m]>
ok with any luck I've got both of those 9.2.9 mutex/condition issues fixed up without too much trouble
<headius[m]>
fwiw that original logging was incorrectly saying we bound it directly even when we did not
<headius[m]>
I think it's a problem of racing thread status and unlocking
<headius[m]>
the old logic would unlock, mark sleeping, and then proceed to sleep
<headius[m]>
the new logic marks sleeping, unlocks, and then proceeds to sleep (by virtue of using lock.newCondition().await() from JDK)
<enebo[m]>
hey do subtypes of String in MRI really still marked as T_STRING?
<headius[m]>
so this and the spec immediately after it fail now because I can't mark sleep within await
<enebo[m]>
Seems like they can't
<headius[m]>
yeah T_* is the native type
<headius[m]>
the struct
<enebo[m]>
yeah so class Foo < String will still be T_STRING?
<headius[m]>
I'm 96% sure of that
<enebo[m]>
ok well then blerg
<headius[m]>
it's like our RubyString
<enebo[m]>
out checkStringType has some mild incompatibility
<headius[m]>
🤯
<enebo[m]>
it may be that the capture struct via RTYPEDATA ends up erroring out when to_str returns nil
<headius[m]>
ah yeah I think that's not supposed to happen
<enebo[m]>
I guess I will look at the specific case
<headius[m]>
I mean it's supposed to TypeError if it returns nil or something, yeah?
<headius[m]>
like to_str is not allowed to return non-String
<enebo[m]>
I obviously can and probably will fix it at this one site because 9.2.9 but I need to understand this
<enebo[m]>
yeah I would say it should but I could with 0% confidence say if I change our checkStringType to do this we would not have something odd happen
<headius[m]>
I an not sure how to handle this beyond moving to actual thread status
victori has joined #jruby
<headius[m]>
I can't mark thread as sleeping using our mechanism from within the condition.await call
<headius[m]>
and I can't sleep on the condition without the lock still being active, so I can't unlock, mark sleep, and then await
<headius[m]>
we have put this off for a while...maybe 9.2.10 needs to start using actual JVM thread status for Ruby thread status
<enebo[m]>
so from an impact perspective what does the current state of things mean for existing users
<headius[m]>
TBH I'm not sure there's not a race at the JDK level, but the logic I see unlocks and then parks
<headius[m]>
I guess I could impl Condition myself but yuck
<headius[m]>
ok so for current users, if they see that thread is sleeping they know the mutex is unlocked
<headius[m]>
with the change, if the thread is sleeping it may still have the mutex for a short time
<headius[m]>
like nanoseconds short time
<headius[m]>
the spec fails because it explicitly tests if the mutex is locked immediately after sleep state is set
<headius[m]>
the problem with the current state is that the sleep doesn't actually sleep on the mutex, it sleeps on some other lock
<headius[m]>
which interferes with concurrency that expects it to be sleeping on the mutex
<headius[m]>
implementing the condition logic myself would not be ideal...have to juggle thread states and LockSupport.park and such
<headius[m]>
and properly unpark thread and mark it alive if interrupted
<enebo[m]>
I am more wondering in terms of ruby-concurrent or something where someone has already written stuff around mutexes which may hit some problem
<enebo[m]>
and I think at this point we should consider which version of this is least problematic