On Thu, Oct 27, 2016 at 4:53 PM, Carsten Haitzler <[email protected]> wrote: > On Thu, 27 Oct 2016 09:05:37 -0700 Cedric BAIL <[email protected]> said: >> On Oct 26, 2016 6:19 PM, "Gustavo Sverzut Barbieri" <[email protected]> >> wrote: >> > barbieri pushed a commit to branch master. >> > >> http://git.enlightenment.org/core/efl.git/commit/?id=574e4b8ad56b0cced409417f76e90205fb28fe22 >> > >> > commit 574e4b8ad56b0cced409417f76e90205fb28fe22 >> > Author: Gustavo Sverzut Barbieri <[email protected]> >> > Date: Wed Oct 26 23:17:10 2016 -0200 >> > >> > efl_io_copier: work around efl_future weirdness. >> > >> > The pointer given to efl_future_use() should be NULL-ified before >> > calling my function, since that pointer has no meaning anymore. >> > >> > The copier relied on pd->job being NULL to avoid useless rescheduling, >> > it was being reached with non-null, but that pointer is no longer >> > useful. >> > >> > Moreover, I'm not sure if the second pointer, with the new future >> > won't be modified to NULL when the efl_future continues :-( >> >> Yes, this is a problem I am well aware off.due to the use of eo for future, >> weak ref are nulled only after the future is destroyed. But the real >> correct behavior is to have it nulled as soon as it is fulfilled before >> even calling any callback, because weak ref are to be used by cancel only. >> They shouldn't exist when cancel can't be called anymore. I intend to fix >> this when I move future away from eo. > > futures should not be moved away from eo. futures are what you cancel and this > discussion is going to go in a circle. because to cancel them you need a > handle > to keep around... they MUST be eo. for safety. for reffing. etc.
You may have missed a few information. Reffing is uneeded as we rely on returning to the main loop to actually trigger a future. We have several problem with eo. First one is weak reference don't behave as they should with future. You want all weak reference to disapear as soon as a promise resolve, not after the future are done. Otherwise you end up with the line of code above. Second problem, if you can efl_future_then on NULL future, you should trigger the fail callback right away. This is not doable in eo without wrapping that call. Other than that, future are using no other feature of eo except for safe pointer. This part of the code in Eo as grown organically to a point where maintenance of it is non trivial already. Moving it to eina with a clean API will solve both problem. Allow a proper testing and benchmarking of that infrastructure along with the reusability for other piece of code who do not need a full scale Eo object. It can even be used for legacy only handler, like Ecore_Animator without confusing people on having legacy Eo object and modern object. So no, there is more problem into keeping future an eo object than moving away from it. Note, we are not talking about promise object here, just future. -- Cedric BAIL ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
