Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Add support for `addLocalChild`

Abierto
  • ¿Algo no está bien?
#400 0 comentarios 0 reacciones 0 asignados Ver en GitHub

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
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
haskell
Área
distributed-systems

Línea de trabajo

Empieza leyendo Control/Distributed/Process/Registry.hs y el módulo Unsafe; después, sigue la API startSup y las rutinas existentes de inicio/reinicio de hijos. Determina cómo las especificaciones de hijos locales pueden seguir sin ser serializables sin afectar a la supervisión ordinaria o remota. Se considera terminado cuando addLocalChild funciona para la supervisión local anidada y la configuración serializable existente del supervisor y los grupos de supervisión remota siguen siendo utilizables.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

distributed-process-supervisor

As per https://github.com/haskell-distributed/distributed-process-registry/blob/master/src/Control/Distributed/Process/Registry.hs, we can pass unserialisable thunks to a supervisor on the same local node, by creating a binary shim to hold the data, and creating a binary instance that simply errors on read and write.

Since the Unsafe module deliberately avoids forcing evaluation of messages, this enables us to safely pass a Process () to a local supervisor, for the purposes of adding it after initialisation.

There are some issues to be observed about this approach...

Firstly, if we wish to add children in this fashion, we might not want to support putting them in the initialisation config for the supervisor. Supporting that notion would make the init config non-serialisable.

We also need to consider whether refactoring the whole code base for this feature is worth it. Perhaps the simplest option that occurs to me, would be to store unclosured child start procs in a map, against the child keys, and when adding a local child, to ignore the closure field and just add the passed proc. So long as code which usually accesses the closure (i.e. The start/restart routines) always checks the map first, this should work fine, with minimal impact.

It could be useful to add an alternate startSup API, that takes LocalChildSpec records instead of the serialisable ones, which should allow for library users to clearly distinguish between supervisors that can be used locally and those which may be deployed to remote nodes. This would get around the issue of having non-serialisable init config.

An interesting issue here is that of nested supervision trees. If a local child spec is for a supervisor, that local child init could indeed contain non-serialisable local child specs, or regular specs.

This change would be incompatible with remote supervision groups, like those that rabbitmq uses to handle load balancing process groups. It would not prevent ordinary supervisor configurationa from being used in those kind of scenarios though...

Lenguaje dominante
Haskell
Estrellas
753
Forks
101
Merge medio
1 d 3 h
PR fusionados (30 d)
4

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de haskell-distributed/distributed-process

Todos los issues de haskell-distributed/distributed-process

Issues similares

Más issues de Haskell

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.