Page MenuHomePhabricator

Fix efl_futur
Closed, ResolvedPublic


efl_futur is broken by design as we are using eo object which have a different lifecycle. At this point fixing it require to either have the insane idea of overwriting the call to efl_ref/efl_unref or to actually get rid of eo object completely. The later is making complete sense as we are already not relying on eo for anything and working around it for weak references.

For this task, we need to :

  • bring eina_safe_pointer to feature parity and speed with what eo use (T5309)
  • cleanup eo use of safe pointer by using eina_safe_pointer (T5304)
  • use eina_safe_pointer directly for efl_futur and get rid of eo (this task)
cedric created this task.Mar 29 2017, 6:55 PM

It should be working for bindings fine and ideally if we could support async/await from C# with it, would be great.

cedric added a comment.Apr 4 2017, 4:27 PM

It should also provide an easier to use interface for Eina_Value as it will be heavily used by our data model and view. Maybe the possibility to have helper that will automatically take care of setting up the Eina_Value like :

efl_promise_double_set(promise, 0.0);
efl_promise_bool_set(promise, EINA_TRUE);

And on the other side a way to register type safe callback using inline code like (As future require manual binding anyway, we can add some nice infrastructure there) :

static void then_success_bool(void *data, const Efl_Event *ev, bool value);


You don't need safepointer... actually given the amount of usage of promise/future in Efl once it's deployed (jobs, timers, idlers...) we should be using mempool, then we can use a mempool property to safety-check based on that. Like you always allocate multiple of pagesize() blocks, keep a list of blocks. Upon API entry, check if the pointer is inside one block. If so, check if the slot is alive.

This would give safety and performance at the same time. Let's remember both Promise and Future are short lived and you're not calling many methods on them! Most of the methods you call is to invalidate it! Like fulfilling or error a promise; canceling a future.


Please stick to fulfill and error (or fail), if you go with efl_promise_XXX_set(), it looks like you can later set it again... which is not the case. Both fulfill or error will invalidate the promise once it returns.


This will break hell... let's not get into this, if we wait we not only create bad practice we may run into situations where we'd need to run the main loop, which could generate other events... inner main loops are always an issue.

  • I guess we can indeed have a fast check for if a pointer belong to a mempool. Didn't think about this. Ok will go with that.
  • So going with efl_promise_XXX_fulfill for all the helpers ?
  • Wait ? What ? Ah, no, this is related to C#, not C. I am wondering how C# environment do implement this behavior and how we can deal with it. They looks like a coroutine, but not so sure. It is important to look at it as this is how MVVM is implemented in C#. We may have to find a way to connect C# Model with EFL View. This is at this point an investigation point, but definitively, not something to ditch.
barbieri added a comment.EditedApr 10 2017, 7:51 PM

yes, efl_promise_fulfill(Promise, Eina_Value) and variants like efl_promise_fulfill_bool(Promise, Bool)

need to check what's C# expectation, on our side, unless the promise is being executed on another thread, I don't see any way to "wait" unless we execute the main loop.

If we're the view, I don't see why we'd need a "wait" to connect to C# model... we'd be using the async patterns. The other way around could be problematic.

barbieri closed this task as Resolved.Sep 4 2017, 9:13 AM
barbieri added a subscriber: iscaro.

New implementation by @iscaro landed with 5bd8c9a78d7bc21a956b775fb250e8e14711d5b9

zmike edited projects, added efl: mvvm, efl (efl-1.22); removed Restricted Project, efl.Jan 9 2019, 12:10 PM