( kisg | 2019. 10. 19., szo – 07:20 )

A kérdés, hogy mire használjuk ma a fork()-ot? A fork() egyébként, legalábbis Linuxon, nem rendszerhívás, hanem libc függvény és a fork()-ból is clone() lesz mint a pthread_create()-ből.

Csak egy két példa:
- fork() + exec() -> erre mondják a posix_spawn-t
- network szerver: master process accept(), majd fork() -> vannak olyan IPC megoldások, hogy fd-t tudsz rajta átküldeni a worker processeknek, ami sokkal kisebb state sharing, könnyebb biztonságos kódot írni
- heap sharing -> posix shm

A fő problémájuk a fork()-al, hogy nehéz jól használni, és amit használni kéne belőle, azt más szoftver designnal, biztonságosabban, jobb teljesítménnyel meg lehet oldani.

Az tény, hogy rengeteg legacy kód használja, de ha megnézzük a high profile appokat, amik valóban cross platform appok - tehát mennek Windowson is - ott már most meg van oldva a fork() kiváltása.

És itt nem is arról van szó, hogy kidobjuk a fork-ot és a helyét sóval hintjük be. Hanem arról, hogy hogyan, mire oktatjuk a programozókat. Mert sajnos a legtöbb Unix programozó kurzus eljut odáig, hogy "nézd milyen elegáns ez a fork", de a veszélyeiről már nem beszél semmit. Pedig a fork() is bekerülhetne a signal() mellé (meg a Java Thread.stop() mellé), az "ott van az API-ban, de ne használd" kategóriába.