github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 7 June 2013.
01:19 FROGGS joined 03:01 Jimmy__ joined
Jimmy__ diakopter: ping 03:02
diakopter plong 03:03
Jimmy__: ^
Jimmy__ diakopter: not not thread-safe
diakopter: irclog.perlgeek.de/moarvm/2013-06-09#i_7174629 03:04
diakopter but that's why stuff hangs off instance; b/c there could be more than 1 instance
Jimmy__ diakopter: so github.com/MoarVM/MoarVM/commit/30...8e#L7R1233 is not thread-safe also? 03:05
diakopter right 03:06
any in-process cache needs to hang off instance, unless it's non-managed memory such as the unicode names map
(and immutable) 03:07
Jimmy__ diakopter: ok, I'm not good at threads, but per irclog.perlgeek.de/moarvm/2013-06-09#i_7174629, and github.com/MoarVM/MoarVM/commit/15...4c4cc#L0R8 was written by jnthn++, I think we should discuss it with jnthn a bit 03:09
diakopter: :P
Jimmy__ didn't write any threads code...
diakopter okay yes, it's thread-safe assuming all the threads are of the same MVMInstance 03:10
but long-term, it would be nice to be multiple-instance-safe
for instance 03:11
a process that's embedding moarvm
such as perl
might start up thousands of instances one after another if that's what suits it
Jimmy__ diakopter: you're right. I think there should be tc->instance->mutexs->hllconfig_mutex or something?
diakopter right
no need to make a separate malloc'd table for mutexs-> there.. just make instance bigger 03:12
Jimmy__ diakopter: yes
diakopter afk 20 min & 03:14
Jimmy__: there are MANY opportunities for obvious small optimizations in any runtime code that does temporary malloc.. to cache the space 03:15
feels like 30 or so
afk for realz
Jimmy__ diakopter: ok, I think I understand you 03:16
by use fork, and with threads, it's not thread safe 03:17
Jimmy__ still not sure :P 03:20
but should be similar 03:21
03:22 benabik joined
Jimmy__ diakopter: I think some is multiple-instance-safe since they are run once and not use malloc 03:55
04:10 Jimmy__ joined
Jimmy__ hmm, may not sure 04:40
diakopter Jimmy__: malloc is okay 05:00
you just can't store MVMObject process wide
Jimmy__ diakopter: welcome back :P
diakopter or any malloc things that contains MVMObject pointers
or any malloc thing that contains pointers to memory managed by 6model reprs 05:01
Jimmy__ still doesn't know what's wrong when not MVMROOTed
diakopter changing the subject?
or are you asking if those are related?
Jimmy__ well, I feel a headache whenever I try to understand threads-related things. 05:03
diakopter: related 05:04
diakopter they're not related
Jimmy__ or not? 05:05
diakopter wrapping in MVMROOT adds the pointer pointer to a list of roots from which the GC starts as knowing are live 05:06
so it's just to ensure that if the GC runs somewhere within what you wrapped, that pointer gets updated if the GC moved that object 05:07
Jimmy__ diakopter: BTW, you have a changing to libuv doc? 05:11
diakopter yes; PM me a google ID and I'll add you to view it
I mean, they can be public really 05:12
well in a few days anyway
Jimmy__ PMed you 05:19
05:49 Jimmy__ joined
Jimmy__ diakopter: thanks, I'm sure I undertand MVMROOT part now. :P 05:49
06:41 birdwindupbird joined 07:58 eternaleye joined 08:03 lizmat joined 08:19 Jimmy__ joined
Jimmy__ diakopter: ping 08:19
08:26 Jimmy___ joined 08:37 Jimmy__ joined 09:17 eternaleye joined 10:21 cognominal joined 10:23 tomyan joined 10:28 tgt joined 10:38 tomyan joined 10:43 cognominal joined 10:46 cognominal joined 10:54 JimmyZ joined 11:15 JimmyZ joined 11:22 JimmyZ joined 11:24 JimmyZ joined 11:47 tomyan joined 11:59 tomyan joined 12:06 cognominal joined 13:12 cognominal joined 13:54 cognominal joined 13:59 birdwindupbird joined 15:02 cognominal joined 16:03 Ulti joined 17:10 lizmat joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!