( TCH | 2019. 10. 18., p – 20:18 )

Tehát akkor dobjuk ki mindenhonnan a

fork()

-ot, de mit javasolnak helyette?

Három konkrét alternatívát is felsoroltak (

posix_spawn()

,

vfork()

,

clone()

), de ebből a

posix_spawn()

egészen konkrétan nem a

fork()

-nak, hanem a

fork()

+

exec()

kombónak a kiváltására való (ja és még nem tökéletes, de bezzeg a windózos

CreateProcess()

), a másik kettőt meg lehúzták, hogy igazából nem jó, tehát működő drop-in replacementet nem mondtak.

Arról nem is beszélve, hogy a

fork()

-ot nem csak az

exec()

-kel párban szokták használni: ezeken a helyeken az általuk preferált és javasolt

posix_spawn()

nem válthatja ki a

fork()

-ot. Ugyan felsorolnak pár - szerintük már nem életszerű, túlhaladott - példát az

exec()

nélküli

fork()

használatra, de ez meg hiányos, pl. a daemonok is hiányoznak belőle és ott a child process megy tovább a szülő helyett (a szülő kiszáll) és pont ezért ott a legjobb a

fork()

ebből a szempontból, mert ott tényleg az egész process-t másolni kell, címterestől-mindenestől (

vfork()

ezzel ki is esik) kérdés nélkül, amit ugyan lehet, hogy meg lehet oldani pl. a

clone()

segítségével is, de az meg Linux-only...

Ennek megfelelően a

fork()

kihajítására az nem lehet érv, hogy a

posix_spawn()

jobb, mint a

fork()

+

exec()

kombó. Félreértés ne essék, azt nem vitatom, amit leírtak a

fork()

problémáiról, de amíg nincs rá cross-platform POSIX alternatíva, amivel a

fork()

funkcionalitása is 100%-ig megvalósítható, addig nem lehet levesbe küldeni.