Ah, okay, thank you so much for the explanation. So I'll have to use pipes in Perl to detect when the child process ends. Just to be on the safe side, I can collect the terminated child process in Perl (even though waitpid probably won't never be called at the right time here ;- ) )
Am Dienstag, dem 16.06.2026 um 20:42 +0100 schrieb Carsten Haitzler: > On Tue, 16 Jun 2026 05:49:04 +0200 Maximilian Lika via enlightenment- > users > <[email protected]> said: > > > Good morning, > > > > I've been experimenting a bit with fork and pEFL and noticed that > > efl > > seems to override the SIGCHLD signal? In any case, my terminated > > child > > well doesn't "overide" - it sets up a signal handler to begin with. e > does this > because it converts that inot automatically wait()ing on the pid to > collect its > exit status so it isn't a zombie and it reports that exit code in an > event. efl > does this with almost all signals. it converts USR1/USR2 to events > too. it > ignores PIPE and ALRM signals. it converts HUP to an event as well as > QUIT,INT > and TERM become events too in the ecore event loop. more signals are > also > collected and event-ified. this is an ecore policy - make signals > into normal > in-line events int he event queue like all other events. > > > processes appear to be collected by efl before I can collect them > > in > > Perl. Hence my question: Is it safe to override the SIGCHLD signal > > from > > efl and thus regain full control myself? As far as I can see, > > SIGCHLD > > is mainly used in ecore_exe.c and ecore_signal.c: > > no. this will break efl's auto-=collection above where ecore_exe > which spawns > child processes can track exiting/end of the process spawned. > ecore_exe also > handled stdin/out i/o to the child process etc. too and efl handles > multiplexing all of that within the ecore event loop as events. > > > grep -rnw ‘/$path_to_efl_source’ -e “SIGCHLD” > > ./src/bin/elementary/quicklaunch.c:61: sigaction(SIGCHLD, > > &old_sigchld, NULL); > > ./src/bin/elementary/quicklaunch.c:314: sigaction(SIGCHLD, > > &action, > > &old_sigchld); > > ./src/lib/eina/eina_debug.c:614: sigaddset(&newset, SIGCHLD); > > ./src/lib/eina/eina_debug_bt.c:78:// #define SIGCHLD 20 /* to > > parent > > on child stop or exit */ > > ./src/lib/eina/eina_debug_timer.c:169: sigaddset(&newset, > > SIGCHLD); > > ./src/lib/eina/eina_thread_posix.c:97: sigaddset(&newset, > > SIGCHLD); > > ./src/lib/ecore/ecore_exe_posix.c:297: sigaddset(&newset, > > SIGCHLD); > > ./src/lib/ecore/efl_exe.c:443: sigaddset(&newset, SIGCHLD); > > ./src/lib/ecore/ecore_signal.c:74: case SIGCHLD: > > ./src/lib/ecore/ecore_signal.c:219: > > _ecore_signal_callback_set(SIGCHLD, _ecore_signal_callback); > > ./src/lib/ecore/ecore_signal.c:234: sigaddset(&newset, SIGCHLD); > > ./src/lib/ecore/ecore_signal.c:330: sigaddset(&newset, SIGCHLD); > > > > Both are modules that aren't implemented in my Perl binding. So I > > don't > > see any problem with letting Perl handle the cleanup of the child > > processes at the moment? > > it will interfere with things behind the scenes. things inside efl > may spawn > helper binaries and will rely on the above ecore events for i/o and > knowing > when it existed and why. > > > But of course, I don’t know whether ecore_exe, ecore_signal, or > > child > > processes in general need to be managed by EFL in other areas > > (e.g., > > when drawing graphics in Evas or generating thumbnails, etc.). > > > > I’d really appreciate a quick assessment :-) > > > > Thanks in advance, > > Max > > > > > > _______________________________________________ > > enlightenment-users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
