Distribuzione Haskell su un cluster

Question

Ho un pezzo di codice che elabora i file,

processFiles :: [FilePath] -> (FilePath -> IO()) -> IO() 

Questa funzione genera un processo asincrona che esegue un'azione IO. Questa azione IO deve essere inviata a un cluster tramite un sistema di pianificazione del lavoro (ad esempio Slurm).

Perché devo utilizzare il sistema di pianificazione del lavoro, non è possibile utilizzare cloudHaskell per distribuire la chiusura. Invece il programma scrive un nuovo Main.hs contenente i calcoli desiderati, ovvero copia sul nodo del cluster insieme a tutti i moduli da cui dipende e viene eseguito in remoto con "runhaskell Main.hs [opts]". Quindi il processo asincrono dovrebbe richiedere periodicamente al sistema di pianificazione del lavoro (utilizzando threadDelay) se il lavoro è terminato.

C'è un modo per evitare di creare un nuovo Main? Posso serializzare l'azione IO ed eseguirla in qualche modo nel nodo?

Answer 1

Sì. C'è una biblioteca magica chiamata packman. Esso consente di trasformare qualsiasi cosa Haskell in dati (fino a quando non ha IORef s o cose legate a loro.) Qui le cose che avrebbero bisogno:

trySerialize :: a -> IO (Serialized a) 
deserialize :: Serialized a -> IO a 
instance Typeable a => Binary (Serialized a) 

Sì, quelli sono i tipi esatti. È possibile impacchettare le azioni IO utilizzando trySerialize, utilizzare Binary per trasferirlo ovunque, quindi deserialize per ottenere l'azione IO, pronta per l'uso.

Avvertenze per packman è che:

• Memorizza le cose come thunk. Questo è probabilmente quello che vuoi, in modo che il nodo possa fare la valutazione.
  • Detto questo, se il tuo thunk è enorme, il Binary sarà probabilmente enorme. La valutazione del thunk può risolvere questo problema.
  • Come ho detto, i riferimenti mutabili sono un no-no. Una cosa da tenere d'occhio è che sono all'interno dei thunk senza che tu lo sappia.

Oltre a questo, questo mi sembra quello che vuoi!