|
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
|
|||