|
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 | ||
| *s/hind/kind/ | |||
| 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
|
|||