Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-08-12

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:53 dalek joined #moarvm
03:16 unmatched} s: Any, "push", \()
07:43 dalek joined #moarvm
08:09 zakharyas joined #moarvm
10:27 lizmat jnthn: do we have a way to stop a thread from running from another thread ?
11:50 lizmat hmmm... if I JIT-log: MVM_JIT_LOG=1 6 'for ^1000000 { .Str }
11:51 lizmat there are 2 occurrences of Str being JITTED in there, one appears to be somewhere in the setting
11:51 lizmat the second one appears to be the Int.Str case (which is what I expected)
11:52 lizmat 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 lizmat could it be that it gets confused about having 2 Str in there ?
12:24 edehont joined #moarvm
13:08 jnthn lizmat: No, and you can't ever safely do that :)
13:09 jnthn (stop another thread)
13:09 jnthn Because it might be holding locks
13:10 jnthn 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 jnthn A better mechanism is to have a way for an exception to be thrown inside of another thread
13:10 lizmat well, I'd be for that as well  :-)
13:11 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:12 jnthn For the case when it's doing something compute-bound is rather easier.
13:12 lizmat ok, this is about RT #128900
13:12 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=128900
13:12 jnthn What are you wanting it for, ooc? Ctrl+C support in the REPL?
13:12 lizmat yup
13:13 lizmat got it working to the point that it ignores the EVAL after a control-C has been done
13:13 lizmat but this looks like some internal state not being reset properly after the control-c
13:14 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 jnthn *set off
13:14 lizmat https://gist.github.com/lizmat/ca54ab85f554307d2fa3b0ec12687d56
13:14 lizmat basically, there's another Promise that gets kept when you press control-c, which breaks the await
13:15 lizmat 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
13:16 lizmat yeah, figured that
13:16 jnthn So it's dieing in a totally unrelated thread :)
13:16 lizmat yup
15:31 edehont joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary