no, please no!

raster, I know you want to simplify things and all, but really loop
shouldn't expose process signals, they have nothing to do with them.

we should have a process object... with at least one that represents
your own process, auto-created on fork and when the app is launched...
THAT object would expose such signals as events.

that's the proper way to do, without polluting the efl.loop with
things like that.


On Sat, Jan 6, 2018 at 7:51 AM, Carsten Haitzler <[email protected]> wrote:
> raster pushed a commit to branch master.
>
> http://git.enlightenment.org/core/efl.git/commit/?id=f62e0513435de1115e454fa4e8ad61c906b2c5e5
>
> commit f62e0513435de1115e454fa4e8ad61c906b2c5e5
> Author: Carsten Haitzler (Rasterman) <[email protected]>
> Date:   Sat Jan 6 18:49:07 2018 +0900
>
>     efl signals - add signal callbacks for minimal signal set on loops
>
>     this willonly apply to the main loop, but to be able to see these
>     signals as callbacks, we have to expose them. term/quit/int are
>     already handled internally where the loop will terminate (efl will
>     enforce this) AND ... there is a terminate event already on the loop
>     to deal with this cleanup. other signals really arent applicable IMHO
>     except usr1/2 and hup.
> ---
>  src/lib/ecore/ecore_signal.c | 15 +++++++++++++--
>  src/lib/ecore/efl_loop.eo    |  3 +++
>  2 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/src/lib/ecore/ecore_signal.c b/src/lib/ecore/ecore_signal.c
> index e4f33de815..1d9872a459 100644
> --- a/src/lib/ecore/ecore_signal.c
> +++ b/src/lib/ecore/ecore_signal.c
> @@ -41,7 +41,7 @@ typedef struct _Signal_Data
>  } Signal_Data;
>
>  static Eina_Bool
> -_ecore_signal_pipe_read(void)
> +_ecore_signal_pipe_read(Eo *obj)
>  {
>     Signal_Data sdata;
>     int ret;
> @@ -69,6 +69,14 @@ _ecore_signal_pipe_read(void)
>                    ecore_event_add(ECORE_EVENT_SIGNAL_USER, e,
>                                    _ecore_signal_generic_free, NULL);
>                 }
> +             Eo *loop = efl_provider_find(obj, EFL_LOOP_CLASS);
> +             if (loop)
> +               {
> +                  if (sdata.sig == SIGUSR1)
> +                    efl_event_callback_call(loop, 
> EFL_LOOP_EVENT_SIGNAL_USR1, NULL);
> +                  else
> +                    efl_event_callback_call(loop, 
> EFL_LOOP_EVENT_SIGNAL_USR2, NULL);
> +               }
>            }
>          break;
>        case SIGHUP:
> @@ -80,6 +88,9 @@ _ecore_signal_pipe_read(void)
>                    ecore_event_add(ECORE_EVENT_SIGNAL_HUP, e,
>                                    _ecore_signal_generic_free, NULL);
>                 }
> +             Eo *loop = efl_provider_find(obj, EFL_LOOP_CLASS);
> +             if (loop)
> +               efl_event_callback_call(loop, EFL_LOOP_EVENT_SIGNAL_HUP, 
> NULL);
>            }
>          break;
>        case SIGQUIT:
> @@ -120,7 +131,7 @@ _ecore_signal_pipe_read(void)
>  static void
>  _ecore_signal_cb_read(void *data EINA_UNUSED, const Efl_Event *event 
> EINA_UNUSED)
>  {
> -   while (_ecore_signal_pipe_read());
> +   while (_ecore_signal_pipe_read(event->object));
>  }
>
>  static void
> diff --git a/src/lib/ecore/efl_loop.eo b/src/lib/ecore/efl_loop.eo
> index c91709509a..66ff276f0e 100644
> --- a/src/lib/ecore/efl_loop.eo
> +++ b/src/lib/ecore/efl_loop.eo
> @@ -151,6 +151,9 @@ class Efl.Loop (Efl.Object)
>        pause; [[Called when the window is not going be displayed for some 
> time]]
>        resume; [[Called before a window is rendered after a pause event]]
>        terminate; [[Called before starting the shutdown of Elementary]]
> +      signal,usr1; [[System specific, but on unix maps to SIGUSR1 signal to 
> the process - only called on main loop object]]
> +      signal,usr2; [[System specific, but on unix maps to SIGUSR2 signal to 
> the process - only called on main loop object]]
> +      signal,hup; [[System specific, but on unix maps to SIGHUP signal to 
> the process - only called on main loop object]]
>     }
>     implements {
>        Efl.Object.constructor;
>
> --
>
>



-- 
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (16) 99354-9890

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to