On Thu, Jan 4, 2018 at 9:56 AM, Andy Williams <a...@andywilliams.me> wrote:
> ajwillia-ms pushed a commit to branch master.
>
> http://git.enlightenment.org/core/efl.git/commit/?id=e931fd698d26b8bec0e34239d2f79c059b339a51
>
> commit e931fd698d26b8bec0e34239d2f79c059b339a51
> Author: Andy Williams <a...@andywilliams.me>
> Date: Thu Jan 4 11:56:01 2018 +0000
>
> promise: Add even simpler helper for main loop promise creation
> ---
> src/lib/ecore/Ecore_Eo.h | 12 ++++++++++++
> src/lib/ecore/efl_loop.c | 10 ++++++++++
> 2 files changed, 22 insertions(+)
>
> diff --git a/src/lib/ecore/Ecore_Eo.h b/src/lib/ecore/Ecore_Eo.h
> index fa5d08d798..4c6783cd5f 100644
> --- a/src/lib/ecore/Ecore_Eo.h
> +++ b/src/lib/ecore/Ecore_Eo.h
> @@ -83,6 +83,18 @@ EAPI Eina_Future_Scheduler
> *efl_loop_future_scheduler_get(const Eo *obj);
> */
> EAPI Eina_Promise *efl_loop_promise_new(const Eo *obj,
> Eina_Promise_Cancel_Cb cancel_cb, const void *data);
>
> +/**
> + * @brief Create a future attached to the main loop
watch out the terms... they are confusing, I always mix them up... and
so you did ;-)
s/future/promise/
promise is the "write side" of the pipe... you send the value to it
(resolve/reject) and then it will propagate to the read side in a
chain of futures.
> + * @param cancel_cb A callback used to inform that the promise was canceled.
> Use
> + * this callback to @c free @p data. @p cancel_cb must not be @c NULL !
> + * @param data Data to @p cancel_cb.
> + * @return A promise or @c NULL on error.
> + *
> + * @see eina_promise_new()
> + */
> +EAPI Eina_Promise *efl_loop_main_promise_new(Eina_Promise_Cancel_Cb
> cancel_cb, const void *data);
...
> +EAPI Eina_Promise *
> +efl_loop_main_promise_new(Eina_Promise_Cancel_Cb cancel_cb, const void *data)
> +{
> + Efl_Loop *main;
> +
> + main = efl_loop_main_get(EFL_LOOP_CLASS);
however this shouldn't exist, really.
as I wrote in my previous long-long-email, creating PROMISES is not
common. Basically internal EFL code is doing that, like
timeout/job/idle promises that are returned as FUTURE... then the user
will chain on those futures... no need to create and return a new
promise. There is no need for helping it that much.
that said, providing a helper to do it for the "main" loop is wrong,
because people should be careful to stick with the existing main loop
they are bound to and never-EVER assume there is a single main loop
and they are running from it.
for the time being, things will work, after all we have a single
loop... but once we make it really possible to have multiple loops,
then things start to misbehave and it will be super-hard to fix...
since things won't crash, they won't fail to compile... they will just
be dispatched "elsewhere" and eventually this is freaking hard to
identify.
a good quality check for EFL would be to identify code as
"efl_loop_main_get()" or others that assume a main loop instead of
propagating using loop/loop-user... and mark as a bug.
--
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
