Standardowe podejście do określania powodzenia lub niepowodzenia fork/exec (gdy rodzic działa jednocześnie)?

Question

Zrobiłem program przy użyciu fork() i exec*(). Problem polega na tym, że nie mogę stwierdzić sukcesu lub niepowodzenia exec() z procesu nadrzędnego, ponieważ jest on w oddzielnym procesie potomnym. Myślę, że rodzaj sygnalizacji może być użyty do sprawdzenia tego stanu, ale nie mam o tym pojęcia.

1. Jaki jest zalecany/standardowy/powszechnie stosowany sposób sprawdzenia tego?
2. A jakie są pułapki, którymi muszę się przejmować, robiąc to?

---

Pytanie Szczegóły Aktualizacja (przepraszam za pominięcie ważnych szczegółach)

chcę zachować oba procesy są uruchomione, więc nie można po prostu czekać wyjściu z procesu potomnego. Innymi słowy, chcę być powiadamiany o procesie potomnym "exec sukces lub porażka.

Answer 1

Twój proces macierzysty może użyć pid procesu podrzędnego, aby wykryć, że jest on żywy lub zakończył działanie (i może rozróżnić kod błędu oraz zginąć z powodu błędów, patrz waitpid). Możesz użyć określonych kodów błędów lub sygnałów, aby powiadomić rodzica o konkretnych przypadkach błędu (np. W rozwidlonym dziecku przed uruchomieniem), ale dla całkowicie ogólnego dziecka, możesz nie być w stanie zarezerwować żadnych kodów wyjścia lub sygnałów (ponieważ rodzic nie będzie mógł stwierdzić, czy exec się powiódł, a następnie dziecko zakończyło z tymi wartościami).

Innym często stosowanym podejściem jest utworzenie pary fd dla rur (patrz układ "rura") i przekazanie jednego końca do elementu podrzędnego (zwykle koniec zapisu), a drugiego do elementu nadrzędnego. Dziecko może użyć tego do wysłania określonych kodów błędów do rodzica. I rodzic może wykryć przedwczesne zakończenie, jeśli rura jest zamknięta bez uzyskania żadnych danych. Istnieje kilka pułapek: SIGPIPE zostanie wysłane do rodzica, jeśli odczytane zostanie na rurze bez aktywnych pisarzy, a użycie fd (innego niż stdin/stdout/stderr) w procesie potomnym może zmylić niektóre źle napisane procesy potomne (chociaż close-on-exec może pomóc to naprawić).

Ogólnie, cały kod, który widziałem, aby sprawić, że fork + exec jest solidny, jest dość hackowaty.