github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
brrt \o 05:26
samcv \o 05:27
nwc10 o/ 05:30
brrt ohai 05:32
my fork-safety thread crashes because i'm shutting down the io loop too late, it seems :-( 05:46
samcv brrt: so i've been busy for the last bit with my job search, whati's this fork safety thing about? 05:48
fixing a crash?
brrt no 05:53
it's about allowing fork() in MoarVM
samcv oh nice :)
brrt++
brrt in POSIX fork() will copy memory but not threads
since we have a bunch of background threads, that might mean that the child inherits memory that cannot be cleaned up 05:54
including locks that may be held, etc
solving that in the general case of having user threads, is very difficult 05:55
samcv by doesn't copy threads, do you mean subthreads? or what
brrt the child process only ends up with one thread, which is the one that derrives from the fork()-ing threads
MoarVM will have at least a spesh thread, maybe an IO thread, maybe a debugserver thread 05:56
and potentially many user thredas
*threads
samcv so you're saying those threads need to be forked too? or something
since it's not a single process?
or am i totally misunderstanding things
brrt That's almost correct 05:57
you can't make fork() create new threads on the child process
so what you have to do, to ensure that the child process doesn't get stuck with memory it cannot use, is to stop the threads in the parent process, fork then start them again (in the parent, and maybe in the child process) 05:58
samcv ah ok i understand it now 05:59
brrt but we couldn't stop either the IO loop thread, or the spesh thread, so far, so I had to add that first 06:00
so I think i know what's going on now 06:22
brrt hmm, shutting down the uv loop causes a deadlock now 06:33
well, that's progress at least :-)
Geth MoarVM/fork-safety: 0a6fdaec28 | (Bart Wiegmans)++ | src/io/eventloop.c
[IO] Redundant MVM_gc_mark_thread_blocked causes a panic

Maybe panicking is an overreaction, but the mark_thread_block was redundant, as MVM_thread_join would call it again.		 06:38
brrt hmm, i need to figure out how to stop the io event loop 10:44
brrt our windows support is not getting better it seems.... 11:28
t/hll/06-sprintf.t breaks
brrt how even *is* a MoarVM opcode exposed to NQP? 12:30
and more importantly, why doesn't it just work
timotimo they are registered in QASTOperationsMAST 12:31
brrt hmmm
so I need to modify nqp source to register a new op 12:32
and... that doesn't happen automatically based on the MAST/Nodes.nqp or MAST/Ops.nqp 12:34
thank you timotimo++, now I understand a lot more 12:37
Geth MoarVM/master: 6 commits pushed by (Paweł Murias)++, (Bart Wiegmans)++ 13:02
brrt .tell pmurias I merged your PR 13:22
yoleaux brrt: I'll pass your message to pmurias.
brrt I think the MVMROOT there isn't necessary because we already assigned the object to the register... 13:29
oh, hang on, the 'result' variable may be overriden
timotimo there's some extra stuff in the operations like "this argument shall have a decont generated automatically" 13:41
Geth MoarVM: 3abd2888bc | (Bart Wiegmans)++ | 4 files
[decodelocaltime] Throw error on failure

localtime_r and localtime_s can both fail, and we should throw an error if so, otherwise how is the user to know?		 14:17
timotimo hm, wanted to combine usage of debugserver with gdb and seemingly didn't do it right 16:01
brrt what's going wrong 16:03
timotimo i did something and the debug client got stuck :)
let me try it again and see if i can't figure it out 16:07
timotimo hum. 16:15
timotimo well, i can just look closely at the code and fix it that way i'm sure 16:16
m) it was a mistake in the C code, not the nqp code 16:20
timotimo i'd love the rakudo compilation to speed up some more :D 16:49
brrt timotimo: wouldn't we all 18:10
timotimo INSERT INTO types VALUES ('54','NQPArrayIter',json_object('typename', 'NQPArrayIter','type', null,'managed_size', 64),json_object()); 18:19
INSERT INTO types VALUES ('102','BOOTStrArray',json_object('typename', 'BOOTStrArray','type', null,'managed_size', 56,'has_unmanaged_data', 1),json_object());
looks good, doesn't it? 18:20
now there can be any kind of data in there! 18:23
brrt hmm, pretty nice 18:30
what's the backend database?
Geth MoarVM/profiler-extra-type-info: 4 commits pushed by (Timo Paulssen)++ 18:35
timotimo the backend database is sqlite3
oh, cute! github gives you an url where you can create a PR when you've "git push"ed a new branch 18:36
tadzik oh :) I thought only gitlab did that
Geth MoarVM/master: 6 commits pushed by (Timo Paulssen)++ 18:51
brrt I think I figured out how to stop the libuv loop at a distance 18:53
timotimo is it spooky?
brrt not very 18:57
but i'm not 100% sure it will work correctly if we're actually connected to a socket or something
timotimo kicking the debugserver client off is a valid thing to do. not polite, but acceptable 18:59
maybe we should send an event for that case asking to reconnect, and suspend all threads after coming back from the fork on this side of it
also, the debugserver may want to expose controls for what the forked whild does, i.e. should it continue running a debugserver, but on a different port?
brrt hmmm 19:01
it's a good question
but, it is also something that doesn't quite work under gdb
so the state of the art is not really all that exciting 19:02
timotimo so wouldn't it be cool if we did it better ;) 19:02
brrt :-) 19:14
timotimo INSERT INTO types VALUES ('395','Rakudo::Iterator::Mappy-keys',json_object('typename', 'Rakudo::Iterator::Mappy-keys','type', null,'scdesc', 'gen/moar/CORE.setting','repr', 'P6opaque','managed_size', 48),json_object()); 22:21
^- i can now tell objects that are rakudo and nqp builtins apart from objects that aren't (except if they were compiled with the exact same path as the CORE.setting or similar files) 22:22
so if it's a class from the core setting, i can link it to the docs immediately!

Powered by Cro and the Raku® Programming Language.

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

Thank you!