All the runScheduledAction complexity seems to be redundant
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 25/100
- Type d'issue
- Refactorisation
- Clarté
- À clarifier
- Activité
- À l'abandon
- Stack technique
- haskell
- Domaine
- distributed-systems
Piste de recherche
Commencez par comparer les commits référencés 3855e91 et 876a3dc, puis suivez runScheduledAction et sendOn pour comprendre les garanties d’ordre autour de la MVar. Déterminez si la complexité de la planification est redondante et documentez un périmètre concret et testable avant de la modifier.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Simply doing
thingToSend <- modifyMVar (....)
send thingToSendis not good enough, because now if we have to threads doing the above the sends
may be done in the wrong order.
Before https://github.com/haskell-distributed/network-transport-tcp/commit/876a3dc94e516c9ec60ea8b0a65ea3f13b8c1f27 it was true. But after sendOn was protected with MVar it seems that it became redundant, because, as @simonmar states in his book:
if a thread T is blocked in takeMVar and there are regular putMVar operations on the same MVar, it is guaranteed that at some point thread T’s takeMVar will return. In GHC, this guarantee is implemented by keeping blocked threads in a FIFO queue attached to the MVar...
In other words, the first thread called sendOn and blocked on MVar will be served first when the MVar will be available (if I understood correctly the book). So it seems that "simply doing" approach mentioned in the beginning will just do. No?
CC @edsko
- Langage dominant
- Haskell
- Étoiles
- 753
- Forks
- 101
- Merge moyen
- 1 j 3 h
- PR mergées (30 j)
- 4
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de haskell-distributed/distributed-process
-
enhancement Feature Request
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 25/100
haskell-distributed/distributed-process#486 · 1 commentaire · 1 réaction ·
-
discuss enhancement Feature Request
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 25/100
haskell-distributed/distributed-process#478 · 4 commentaires · 3 réactions ·
-
enhancement Feature Request
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 15/100
haskell-distributed/distributed-process#476 · 2 réactions ·
-
Demonstrating the use of Cloud Haskell for a Raft implementationPeut-être à nouveau libre @LaurentRDC l’a pris il y a 482 jours, et aucune pull request n’est ouverte. Ouverteenhancement Feature Request
haskell-distributed/distributed-process#475 · 3 réactions · 1 personne assignée ·
-
Difficulté 4/5 3-5 jours Accessibilité débutants 20/100
haskell-distributed/distributed-process#473 · 4 commentaires · 1 réaction ·
Toutes les issues de haskell-distributed/distributed-process
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
objectionary/phino#2059 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 72/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
NixOS/nixpkgs-update#586 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 83/100
wireapp/wire-server#5632 ·
Les mainteneurs répondent en général sous 2 jours
-
allow tagged-0.9 for ghc-9.14Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 65/100