01:53 dalek joined
unmatched} s: Any, "push", \() 03:16
07:43 dalek joined 08:09 zakharyas joined
lizmat jnthn: do we have a way to stop a thread from running from another thread ? 10:27
hmmm... if I JIT-log: MVM_JIT_LOG=1 6 'for ^1000000 { .Str } 11:50
there are 2 occurrences of Str being JITTED in there, one appears to be somewhere in the setting 11:51
the second one appears to be the Int.Str case (which is what I expected)
however, if I profile the same code, there is only *one* Str mentioned in there, and it is marked as speshed only, *not* JITted 11:52
could it be that it gets confused about having 2 Str in there ?
12:24 edehont joined
jnthn lizmat: No, and you can't ever safely do that :) 13:08
(stop another thread) 13:09
Because it might be holding locks
The history of "have a way to just stop a thread" is pretty entertaining. Java provided it, then deprecated it. Right on their heals, .Net 1 came out with such a method. .Net 2 deprecated it for the very same reason :P 13:10
A better mechanism is to have a way for an exception to be thrown inside of another thread
lizmat well, I'd be for that as well :-)
jnthn I'm good with us having *that* mechanism. However, the implementation of that when said thread is, for example, waiting on a condition variable or contending for a lock or in other blocking situations (IO?) is...very fraught. 13:11
For the case when it's doing something compute-bound is rather easier. 13:12
lizmat ok, this is about RT #128900
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128900
jnthn What are you wanting it for, ooc? Ctrl+C support in the REPL?
lizmat yup
got it working to the point that it ignores the EVAL after a control-C has been done 13:13
but this looks like some internal state not being reset properly after the control-c
jnthn Do you set of the code to run in a thread and wait for the response, and then just break the Promise on the signal, or some such? 13:14
*set off
lizmat gist.github.com/lizmat/ca54ab85f55...ec12687d56
basically, there's another Promise that gets kept when you press control-c, which breaks the await
the simple approach of dieing inside the .tap block, didn't work (unhandled exception in thread) 13:15
jnthn For sure, the signal handler is scheduled on the thread pool
lizmat yeah, figured that 13:16
jnthn So it's dieing in a totally unrelated thread :)
lizmat yup
15:31 edehont joined