On Fri, Nov 24, 2017 at 12:17 AM, Jean-Philippe André <j...@videolan.org> wrote:
> Hi,
>
> Honestly I'm a bit confused by the use of promise/future as the core since
> ecore events aren't single-shot by definition (yes, some of them are). But
> that's beyond the point for my email.
my point is that you handle as single-shot and re-subscribe
automatically. For recurring events, you do not expose the "future"
handle, just register one that, once dispatched will re-subscribe
before calling the user's cb.
> In C++ Felipe implemented eo event callbacks like this:
> event_add(event_type, object, functor);
>
> functor is an object containing the context data and the function pointer.
> It's quite likely to be std::bind() of a lambda only defined in the above
> line.
> So it's not accessible for deletion later. The solution being to keep a
> handle on the connection:
> signal_connection sig = event_add(event_type, object, functor);
> // keep sig somewhere, and later:
> sig.disconnect();
>
> For basic function callbacks (eg. Format_Func_Cb) I think this is not an
> issue as there is only one slot. Just pass null to reset it. But ecore
> events can have multiple listeners.
what I meant is this promise/future for *EACH* listener. so not an
issue. Internally you'd have:
loop->receivers[event_class] = [ listener1, listener2, listener3,
..., listenerN ]
each listener is a future. Once resolves listener1, it will
re-subscribe, then list becomes:
loop->receivers[event_class] = [ listener2, listener3, ...,
listenerN, listener1 ]
once resolver2 resolves:
loop->receivers[event_class] = [ listener3, ..., listenerN,
listener1, listener2 ]
and so on...
> So, I think that if we want to design a generated EO API for ecore events
> from the ground up, we need to keep in mind that only C will be able to
> call event_del() with a C function pointer directly.
event_del here would find an item from loop->receiver[event_class].
It should store cb, data, free_func... and thus finding it is a simple
list walk.
bindings will have the same cb/free_func, but different data.
--
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
