On Mon, Jan 8, 2018 at 3:38 AM, Jean-Philippe André <j...@videolan.org> wrote: > On Fri, Jan 5, 2018 at 3:18 AM, Gustavo Sverzut Barbieri <barbi...@gmail.com >> wrote: > >> On Thu, Jan 4, 2018 at 2:59 PM, Andrew Williams <a...@andywilliams.me> >> wrote: >> > Hi, >> > >> > Apologies for the future/promise gaff - I was working from the >> > documentation of the previous efl_loop_promise_new which also referred to >> > Future. >> > I will correct both. >> > >> > I am confused by the loop semantics. Many times I have been told that our >> > UI work must happen on the main thread, which indicates that such a >> helper >> > would be handy. Is this requirement changing? >> >> in concept, no. In practice it's recommended to propagate the >> resource... as you did in some examples that use the main loop given >> to efl_main(), not assume some "global"... >> >> not happening anytime soon, but in future we could (more like theory) >> move each unrelated/unlinked window to its own thread, each with its >> own "main loop"... then your approach would fail, while the "pass >> along" would work. >> >> anyway, the promises are not specific to main loop... and as I said >> before, it's not common to create *PROMISES* yourself... often you >> chain to some future, such as timer, idler, job... when more is moved >> to promise/future, this could also be some "file read", "directory >> listing" (eio)... thread feedback (ecore_thread still pending >> "eo-ifyication")... >> >> example: >> >> 1) creating a new promise: >> >> I base my promise on something that is not a promise, like when some >> eo event happens. Then I create my promise based on my assigned loop >> (usually you should be a loop user, or have one as parent), then >> return its future. >> >> I proposed to automatically wrap events -> future, with some people >> supporting that... things like "return me a future when the >> efl.io.copier event 'done' happens". It would register the event >> callback, wait for the event to happen, resolve the promise, >> unregister the event callback. This will be a common pattern. >> >> Usually core EFL is the ones expected to do this kind of work. >> > > This sounds useful. Not insanely helpful in C (it only removes a call to > callback_del) but likely useful in bindings.
in practice it's a bit more than that, for good and for bad: --> future will resolve from clean context, not from efl_event callstack that means its deferred, but context is clean, simpler to delete stuff :-) -- 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
