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