Non sono esperto in materia, ma lo farò comunque.
GHC (il compilatore Haskell) può avere uno o più HEC (Haskell Execution Context, noto anche come cap o capacità). Con il flag di runtime +RTS -N <number> o la funzione setNumCapabilities è possibile definire quanti HEC sono disponibili per il programma. Un HEC è un thread del sistema operativo. Lo schedulatore di runtime distribuisce i thread leggeri Haskell tra HEC.
Con la funzione forkOn, è possibile selezionare su quale HEC viene eseguito il thread. getNumCapabilities restituisce il numero di funzionalità (HEC).
La migrazione di thread indica che i thread Haskell possono essere migrati (spostati) in un altro HEC. Il flag di runtime +RTS -qm disabilita questa migrazione del thread.
Documentazione su forkOn afferma che
Come forkIO, ma permette di specificare in quale capacità il filo deve essere eseguito. A differenza di un thread forkIO, un thread creato da forkOn rimane sulla stessa capacità per l'intera durata della vita (i thread di forkIO possono migrare tra le funzionalità in base alla politica di pianificazione).
così con forkOn è possibile selezionare una sola HEC il filo è correva.
Rispetto al forkIO in cui si afferma che
chiamate estere effettuate da questa discussione non sono garantiti da effettuare da qualsiasi thread del sistema operativo specifico; se hai bisogno di effettuare chiamate esterne da un particolare thread del sistema operativo, allora usa forkOS.
Ora, sono forkOn funzioni e +RTS -qm (migrazione filo disabilitato) la stessa cosa? Probabilmente no. L'utente forkOn seleziona in modo esplicito su quale HEC viene eseguito il thread Haskell (ad esempio è possibile inserire tutti i thread Haskell nello stesso HEC). Con +RTS -qm e forkIO i fili Haskell non commutano tra HECS, ma non c'è alcun modo sapere quale HEC il filo Haskell generato da forkIO termina in
Riferimenti:.