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.
03:06 japhb left 03:35 japhb joined 05:43 japhb left 05:45 japhb joined
Woodi patrickb: what is architecture of dedlock prevention ? just list to try later ? 06:09
with async workloads - IMO - it is by definition proper to restart work so if other work/thread can detect unlocked resource that it can proceed 06:11
patrickb: I do not know much on that subject but maybe current implementation is good for some hind of deadlock but still bad for other kind ? I didn't saw any teoretical problem evaluation in public in here... 06:15
patrickb There is no general deadlock prevention mechanism in the supply handling. I haven't tried it, but I think having two supplies both listening on each other will deadlock when they are simultaneously occupied by different threads and each thread needs to enter the other supply. 08:34
The recent fix is about deadlock prevention during the setup of supplies.
Setup in general is single threaded. So the deadlock potential stems from recursions during the setup process. Those are detected and broken by simply queuing the recursive work after the supply block involved is free again. From all I've seen that's enough. 08:37
The issue was with a second mechanism to help with solving deadlock situations. That other mechanism pulled continuations whenever *any* code within certain bounds blocked. (That magic works by injecting a custom Awaiter implementation via a dynamic variable.) This worked fine, but also applied to code and locks completely unrelated to the supply setup logic it was meant to solve. Thus external 08:43
events could influence the lock prevention mechani and in the worst case get that mechanism itself to deadlock.
The fix I ended up with was to simply remove that logic altogether and entirely rely on the other more explicit recursion detection mechanism. 08:45
github.com/Raku/problem-solving/issues/364 is the clearest discussion about that issue. 08:46
Woodi: ^
Woodi checking... 08:59
just in case: those thing are deadlock as in circular waiting on resources and not supply implementation not working as expected, eg. something is just locked ? 09:04
but case of circular locks can't be fully resolved by reordering things, something 3rd need to do "meta" work... or suppliec need to have self-state checking mechanism which will slow down all use cases 09:11
patrickb Are you familiar with the supply / whenever implementation? 09:32
The block following the supply keyword is called every time the supply is tapped. 09:33
the expression following the whenever keyword is tapped on the spot when execution reaches that whenever. So whenevers create chains of supply blocks. One initial tapping will kick off executing all those supply blocks, every time a whenever is reached execution will jump to the next supply block. 09:37
Woodi patrickb: not familiar with implementations, just trying to reason how things work 09:40
patrickb Supply blocks can contain emits. Those are also executed on the spot. Then the bodies of the whenevers listening for that supply are executed. This is the obvious case of a circularity. A core guarantee supply blocks give is: Only ever at most a single thread in each supply block.
Thus that situation would deadlock. 09:42
Woodi yes, whenevers do create "calbacks". so using something that locks on construction times is "intentional" lock... 09:43
patrickb Have to leave... Child woke up...
Woodi in databases deadlocks comes from incidental sources and here logic is intentionally constructed to be interlocking? that can't work in general case 09:46
10:33 japhb left 10:36 sena_kun joined
Woodi patrickb: rereading things opting for "recursive setup" with code execution recreates BEGIN like problems. usually it is nice to setup things up front and then connect all "triggers". maybe whenevers could be done in deep to surface direction? 12:50
also maybe plain whenevers should take SequencialCodeBlock and things like AsyncCodeBlock / LockingCodeBlock should be setup up front and take arguments with supplies and other concurent / parallel stuff? 12:54
13:05 japhb joined 13:13 japhb left 13:15 sena_kun left 13:17 sena_kun joined 13:19 sena_kun left 17:37 sena_kun joined 18:08 japhb joined 18:20 japhb left 19:06 japhb joined 19:27 japhb left 19:48 japhb joined 23:07 sena_kun left