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


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - [email protected]



_______________________________________________
enlightenment-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Reply via email to