<byteit101[m]>
NoMethodError (private method `zfoo' called for 9:Integer)
<byteit101[m]>
I'm not sure what to think of this
<byteit101[m]>
Both options seem somehow wrong
<byteit101[m]>
3.0 does the same as jruby
<headius>
Interesting that 3.0 matches
<headius>
I think this is due to how default visibility is handled in IRB
<enebo[m]>
jruby -e 'def zfoo; 0; end; 9.zfoo'
<enebo[m]>
<main> at -e:1
<enebo[m]>
NoMethodError: private method `zfoo' called for 9:Integer
<enebo[m]>
but I can confirm 2.6.2 only works due to irb
<enebo[m]>
as it gives the same error with -e
<headius>
Right I may have filed an issue about that
<enebo[m]>
headius: I have some comments above (3pm yesterday) on timeout 0.3.0 and our embedded test
<enebo[m]>
It would appear 0.2.0 of timeout would join on the thread made for the timeout and 0.3.0 does not do that which makes the behavior dependent on the timeout thread going away on its own
<enebo[m]>
I do not find this to be a problem personally but it makes the testTimeoutCleanup mostly fail (and sometimes work)
<headius>
Oh I missed your messages
<headius>
Ah that makes sense
<enebo[m]>
yeah no problem. I did not tag you
<enebo[m]>
It is the only reason -Ptest fails
<enebo[m]>
So should we remove the test or advocate for explicit #join added back into timeout?
<headius>
Hmmm
<enebo[m]>
as it stands timeout clean is non-deterministic now
<headius>
I'll have a look
<enebo[m]>
ok
<enebo[m]>
I am guessing MRI kills that thread right away and when they rearranged code it meant saving raise state since I think the join causes something else to raise
<enebo[m]>
"MRI kills" == just happens to work that way due to non-native threading
<headius>
I am not sure how this would sometimes pass
<headius>
there does not seem to be a way to clean up the timeout thread... it just runs forever
<headius>
the new timeout is implemented similarly, with a single timeout thread that handles all requests, but there's no way to shut it down
<headius>
hmmm
<headius>
we do have code to shut down Ruby threads but we don't do it for adopted threads, which I think applies in this case
<headius>
enebo: I think we should file an issue with timeout about there being no way to cleanly terminate it
<headius>
I'm looking into making such a mechanism now
<headius>
registering a thread killer as a shutdown item might be enough
<byteit101[m]>
but dynamic methods in 3.0 and jruby are public
<byteit101[m]>
define_method(:afoo) { 6 }; 9.afoo
<byteit101[m]>
=> 6
<byteit101[m]>
Oops, though I sent that earlier
<headius>
oh no I'm wrong... this is a normal Ruby thread so it won't be seen as an adopted thread, like the old executor version was
<headius>
so it is probably due to the kill of the threads not completely finalizing their termination during shutdown
<headius>
but we can also make it more robust by having the timeout library register something to kill the timeout thread directly
<headius>
I have a snippit of code that adds an at_exit thread killer and it is passing so far
<headius>
it's not much more than we were already doing but it is done earlier in the shutdown sequence to the thread has more time to clean up before we test for it
<headius>
there's also been some minor tweaks to timeout that could use a release
<enebo[m]>
cool. That looks reasonable to me and it should have no affect on MRI from a performance standpoint
<enebo[m]>
well not one that could matter
<headius>
yeah might get some pushback since we are supposed to shut down threads at termination, but I think it is just too close to the test
<headius>
we do kill+join but the native thread may take a bit more time to no longer show up in JDK lists
<enebo[m]>
We may never shut down too
<enebo[m]>
Not in this case but we just had that backedge fix
<enebo[m]>
There are cases where we cannot know we can kill something
<enebo[m]>
like possibly a Ruby thread which is calling into a Java method which never comes back
<headius>
yeah true
<headius>
we do no more than try a Ruby kill, which won't interrupt everything
<enebo[m]>
Maybe that is too generic but it just is saying we have less control over a threads lifetime than C Ruby.
<enebo[m]>
Another random thought on this whole gemification is that we perhaps need more ability to inject specific impl behavior when not all impls need the same thing
<enebo[m]>
we can RUBY_ENGINE protect this of course
<enebo[m]>
but maybe there is a nicer way
<headius>
inject atop the installed gem or within it?
<enebo[m]>
something. I am not sure.
<headius>
there are other gemified libraries that ship special code for JRuby already, like digest
<enebo[m]>
maybe RUBY_ENGINE is the way
<headius>
or io/wait which is FFI-based for us but an ext for others
<enebo[m]>
if they do not like this for MRI we can at least add it for only us and then it will be committed there
<enebo[m]>
It is just too bad there is not an impl hook all gems could use which would allow impl-specific additions or an additional require or something
<headius>
enebo: do you have a repro for that null block thing you changed?
<headius>
hey we could just stub out all the gems and ship whatever we want