Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:15 sena_kun left 07:05 Util left 07:07 Util joined 07:44 sena_kun joined
lizmat And yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2024/01/22/2024-04-marrow/ 12:40
18:27 slicer joined
slicer Hello, 18:49
I'm trying to gain insights from MoarVM, and I do have a question:
Given that concurrent access to VMArrays is considered erroneous, does it mean arrays in MoarVM are never shared across OS threads? If so then how does Raku synchronize concurrent access to shared arrays? Is this synchronization implemented in the Rakudo project, or is it implemented at all? So far only ConcBlockingQueue sync its operations. Thanks
for a reply.
19:10 slicer left 19:20 slicer joined 19:26 slicer left 19:31 slicer joined
lizmat slicer: VMArrays and VMHashes *are* shared between all threads: code accessing them should make sure that only one thread accesses / mutates at a time 19:41
the Raku concepts of: react whenever { ... } help with that, because the code inside the whenever is guaranteed to be run by one thread at a time 19:42
afk& 19:43
20:04 slicer left 20:26 slicer joined 20:30 slicer82 joined 20:31 slicer left
slicer82 Thanks lizmat, so we will need to explicitly lock using Lock when accessing these data structures in start { ... } and APIs like Thread and Promise? 20:31
20:37 slicer82 left
lizmat slicer: you can, but as I said, there are constructs in Raku that will take care of that for you 22:38
tellable6 lizmat, I'll pass your message to slicer82
23:34 sena_kun left