Nie jestem ekspertem w tej sprawie, ale mimo to dam mu szansę.
GHC (kompilator Haskella) może mieć jeden lub wiele HEC (Kontekst wykonania Haskella, znany również jako cap lub capability). Dzięki funkcji runtime flag +RTS -N <number> lub setNumCapabilities można zdefiniować, ile tych HEC jest dostępnych dla programu. Jeden HEC to jeden wątek systemu operacyjnego. Harmonogram runtime dystrybuuje lekkie wątki Haskell pomiędzy HEC.
Dzięki funkcji forkOn możliwe jest wybranie HEC, w którym wątek jest uruchamiany. getNumCapabilities zwraca liczbę możliwości (HEC).
Migracja wątków oznacza, że wątki Haskell mogą być migrowane (przenoszone) do innego HEC. Flaga runtime +RTS -qm wyłącza migrację wątków.
Dokumentacja o forkOn stwierdza, że
Jak forkIO, ale pozwala określić, na których możliwość należy uruchomić wątek. W przeciwieństwie do wątku forkIO, wątek utworzony przez forkOn pozostanie na tym samym poziomie przez cały okres jego istnienia (wątki forkIO mogą migrować między możliwościami zgodnie z polityką planowania).
więc z forkOn to możliwe, aby wybrać pojedynczą HEC wątek jest prowadzony w.
porównaniu do forkIO który stwierdza, że
rozmowy zagraniczne dokonywane przez tego wątku nie są gwarantowane być wykonane przez dowolny określony wątek systemu operacyjnego; jeśli potrzebujesz wywołań obcych do określonego wątku systemu operacyjnego, użyj zamiast tego forkOS.
Teraz funkcja forkOn i +RTS -qm (wyłączone migrowanie wątków) to samo? Prawdopodobnie nie. Z forkOn użytkownik jawnie wybiera, który HEC wątek Haskell jest uruchomiony (na przykład możliwe jest umieszczenie wszystkich wątków Haskell w tym samym HEC). Z +RTS -qm i forkIO gwinty Haskell nie przełączać się między HECS, ale nie ma mowy, wiedząc, który HEC wątek Haskell zrodził przez forkIO kończy się
Referencje.