All the runScheduledAction complexity seems to be redundant
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Refactorización
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- haskell
- Área
- distributed-systems
Línea de trabajo
Comienza comparando los commits referenciados 3855e91 y 876a3dc; después, sigue runScheduledAction y sendOn para entender las garantías de orden alrededor de la MVar. Determina si la complejidad de la programación es redundante y documenta un alcance concreto y comprobable antes de cambiarla.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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
- Lenguaje dominante
- Haskell
- Estrellas
- 753
- Forks
- 101
- Merge medio
- 1 d 3 h
- PR fusionados (30 d)
- 4
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de haskell-distributed/distributed-process
-
failed to build with time-1.15Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
-
enhancement Feature Request
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
haskell-distributed/distributed-process#486 · 1 comentario · 1 reacción ·
-
discuss enhancement Feature Request
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
haskell-distributed/distributed-process#478 · 4 comentarios · 3 reacciones ·
-
enhancement Feature Request
Dificultad 5/5 Más de una semana Aptitud para principiantes 15/100
haskell-distributed/distributed-process#476 · 2 reacciones ·
-
Demonstrating the use of Cloud Haskell for a Raft implementationQuizá libre de nuevo @LaurentRDC la tomó hace 481 días y no hay ningún pull request abierto. Abiertoenhancement Feature Request
haskell-distributed/distributed-process#475 · 3 reacciones · 1 asignado ·
Todos los issues de haskell-distributed/distributed-process
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
objectionary/phino#2059 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
NixOS/nixpkgs-update#586 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
koalaman/shellcheck#3593 ·
-
Make node sockets moduleAbiertoconfiguration
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
tweag/cardano-kosmos#47 ·
Los mantenedores suelen responder en 1 día
-
documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Los mantenedores suelen responder en 3 días