jmalves_ has quit [Remote host closed the connection]
jmalves has joined #jruby
jmalves has quit [Remote host closed the connection]
jmalves has joined #jruby
jmalves has quit [Ping timeout: 268 seconds]
mengu has joined #jruby
mengu has quit [Ping timeout: 246 seconds]
mengu has joined #jruby
mengu has quit [Ping timeout: 250 seconds]
lucasb has quit [Quit: Connection closed for inactivity]
mengu has joined #jruby
mengu has quit [Ping timeout: 250 seconds]
mengu has joined #jruby
mengu has quit [Ping timeout: 240 seconds]
jmalves has joined #jruby
jmalves has quit [Remote host closed the connection]
jmalves has joined #jruby
mengu has joined #jruby
mengu has quit [Ping timeout: 244 seconds]
<kares> codefinger: hey, have seen these from time to time but mostly in normal jruby runs - a clean build helps
<kares> not sure you can do smt like that while warbling ...
<kares> but there must be 2 of those jars around, somewhere
mengu has joined #jruby
mengu has quit [Ping timeout: 268 seconds]
jmalves_ has joined #jruby
jmalves has quit [Ping timeout: 272 seconds]
jmalves_ has quit [Remote host closed the connection]
jmalves has joined #jruby
lucasb has joined #jruby
Aethenelle has joined #jruby
ilbelkyr has quit [Killed (Sigyn (BANG!))]
ilbelkyr has joined #jruby
xardion has quit [Remote host closed the connection]
xardion has joined #jruby
subbu is now known as subbu|lunch
subbu|lunch is now known as subbu
rdubya has quit [Quit: Leaving.]
rdubya has joined #jruby
rdubya has quit [Client Quit]
rdubya has joined #jruby
rdubya has quit [Client Quit]
rdubya has joined #jruby
rdubya has quit [Quit: Leaving.]
knu has quit [Quit: Reboot...]
knu has joined #jruby
travis-ci has joined #jruby
<travis-ci> nomadium/jruby (ruby-2.6-add-dir-instance-each-child-and-children:4ac5f09 by Miguel Landaeta): The build is still failing. (https://travis-ci.org/nomadium/jruby/builds/470658268)
travis-ci has left #jruby [#jruby]
rdubya has joined #jruby
subbu is now known as subbu|away
<headius> kares: I Think that Mutex failure is a bad spec
<headius> did you have some other evidence that there's something broken with Mutex?
<headius> The spec tries to test for blocking by checking for a thread status of "sleep", but there's a race because we have to set sleep briefly before attempting to lock the lock
<headius> so once in a while it will see the sleep status even though locking the lock doesn't block
<headius> looks like the logic for checking blocking is not new but this particular spec was modified recently to use it
<headius> oops, actually it looks like eregon added this about a week after thanksgiving
<headius> so that would be the week before before 9.2.5
<headius> I will tweak lock to try before setting sleep and blocking
<headius> there will stil lbe a status race but an unlocked lock should never look like it's blocking
<headius> updated mutex issue...I think we're fine
<headius> I also checked other lock impls and I'm pretty sure that core race is unavoidable
<headius> even JVM has a race between setting the waiting status when acquiring a lock
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:39fbea8 by Charles Oliver Nutter): The build was fixed. https://travis-ci.org/jruby/jruby/builds/470688396 [173 min 39 sec]
travis-ci has left #jruby [#jruby]
slyphon has quit [Read error: Connection reset by peer]
slyphon has joined #jruby
subbu|away is now known as subbu
<kares> +1
jmalves_ has joined #jruby
jmalves has quit [Ping timeout: 268 seconds]
jmalves_ has quit [Remote host closed the connection]
jmalves has joined #jruby
jmalves has quit [Ping timeout: 250 seconds]