github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
Geth MoarVM: jstuder-gh++ created pull request #963:
Exprjit: Macros & Alterations		 04:55
brrt \o 08:50
i've reached the actually messy part of fork-safety - fork()-ing :-) 08:51
lizmat
.oO( never run with forks! )
 08:52
brrt hmmm 08:57
so here is my worry, right
- this becomes much simpler if I can assert that the current forking thread is the only thread running
- but potentially, and i'm not 100% sure this is actually true, but bear with me - the eventloop thread might actually start a new thread before it shuts down due to my signal 08:58
I'm not sure if the eventloop thread actually runs arbitrary MoarVM code 08:59
brrt so. I can only assert that I have no other threads running, as soon as I have already shut down the spesh and eventloop thread 08:59
And the other thing - the eventloop thread is autovivified 09:00
lizmat brrt: and there is currently no way to stop it, but that could be easily fixed
brrt I can stop the eventloop thread alright, I'm at that stage
Hmmm. So I guess I'm saying I must be able to prevent it from being autovivified 09:01
lizmat then we have the worker threads
no?
why would you?
brrt during the fork
lizmat *during* the fork ? 09:02
brrt during the fork process, I need to emulate being single-threaded
brrt otherwise, I'm going to be left with a mess of an address space in the child 09:02
because the child does not inherit the threads of the parent, only the forking thrad 09:03
*thread
lizmat ah, so you're saying: it should stop the thread, but *not* lose any queues with things to get done ?
brrt that, too 09:08
that is actually the nastier of the two bits, because we cons a new uv_loop for every threadcontext. 09:09
actually
I don't need to destroy the original threadcontext, or the uv_loop_t, if I'm about to restart it 09:10
I kind of want to remove our 'default' uv_loop, since we only ever use it for dirops (I think), and we *never* run it
but that is another matter for another day 09:12
jnthn brrt: The event loop thread doesn't ever run bytecode 09:14
yoleaux 08:18Z <lizmat> jnthn: I think we need a decoder.reset function, as otherwise we will have to fetch the $!decoder from the $!handle for each .pull-one in the GetLineFast iterator
08:22Z <lizmat> jnthn: case in point: my $h = open("ten"); for $h.lines { .say; $h.close }
jnthn It communicates entirely by queues and is entirely C code
As for starting it - you can find out if it's already being started as part of the code to stop it, and if you know you're in the only thread that's currently running, you know nothing else can trigger starting of it. 09:15
So I don't think it's a big issue.
brrt that's a relief
jnthn .tel lizmat I'll look at it next week. 09:16
.tell lizmat I'll look at it next week.
yoleaux jnthn: I'll pass your message to lizmat.
lizmat jnthn: ok
yoleaux 09:16Z <jnthn> lizmat: I'll look at it next week.
lizmat I guess we can live with an LTA error for the time being 09:17
jnthn We have for a long time, no? :) 09:26
jnthn So a few more days ain't going to be much difference :) 09:26
lizmat well, would have been nice to get it into this release 09:28
but it's not marked as a blocker, so we're good in that sense 09:29
AlexDaniel what's the ticket? 09:33
lizmat R#2272
synopsebot R#2272 [open]: github.com/rakudo/rakudo/issues/2272 [IO][UNI][testneeded] Closed handles are still readable for some time
jnthn The whole point of time-based releases is that you don't worry about getting X change into Y relesae, we just - modulo fixing regressions - ship what's there :) 09:34
AlexDaniel that's right 09:35
this is an old issue so I guess it's fine
Geth MoarVM/master: 5 commits pushed by (Jeremy Studer)++, (Bart Wiegmans)++ 11:53
brrt` hmmm. maybe we can coalesce the lock for event_loop_start with threads 12:37
diakopter I wonder how to add a tailcall thing to nqp 13:03
brrt` You translate it to goto? 13:32
jnthn Gotta deal with the args somehow 13:33
lizmat R#2276 # jnthn: thoughts ? 13:42
synopsebot R#2276 [open]: github.com/rakudo/rakudo/issues/2276 [@LARRY][NYI][consistency][question] What should the * twigil do as a parameter?
Geth MoarVM/fork-safety: 6 commits pushed by (Bart Wiegmans)++ 17:44
Geth MoarVM: 51f2db5798 | (Samantha McVey)++ | src/io/io.c
Add support in write_fhb op for writing 16 bit VM arrays

This allows us to now output utf16 type objects from Rakudo, since these are 16 bit arrays.		 20:56

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!