Hi, I talked to raster for clarification.
2017-11-22 14:57 GMT+09:00 Carsten Haitzler <ras...@rasterman.com>: > So we had a partly done move to efl_loop. it still was all built on top of > the > main loop globals. If this is all done right then we can have multiple > loops > (e.g. one per thread) and that is a good thing. > > So I've been fixing that. I've done just about all the globals in ecore > EXCEPT > ecore events. I now have to think about how to do this in eo/interfaces > with > efl loop objects and so on. I'm mulling how to do it. > > We still have some need for a deferred event bus/queue. A lot of things > that > are ecore events should be callbacks on objects directly and that's being > fixed, but an event queue + types is still needed. > > So there are a few aspects to this. > > 1. Creating of new event types at runtime (and allocating a unique > identifier > for them). > 2. Being able to submit them to a queue to be "processed later" > 3. Being able to call callbacks that are listening for that type of event > and > hand them the deferred event data. > > This is used as the backing for ecore_jobs and pretty much every i/o thing > (input events, i/o and more) as well as in-process custom event bus+events. > > My current thought is this. > > 1. event types are still ints with a single global shared backing table of > all > event types (allocated once ever much like atoms in x). > 2. event event is an eo object on the queue (of some type). > 3. some event object "factory" on the loop that creates and "deletes" > (caches > then) these event objects for recycling. > > Does anyone have better ideas? I considered the event type being an object > itself and also doubling as a factory per event type but due to multiple > threads you'd probably be creating an object then per thread per event > type and > I do not like that. Basically we have two base EO types: - "ecore event type" EO class: singleton per loop, it's a handle you can request the loop for the handle given the UUID contains the read-only UUID, maybe a string description, and an EO event "received" or whatever created and managed by the Efl.Loop (each Loop would need to create their own handles) listeners add an EO callback for "received" to that handle, this keeps the listeners list per loop the loop has a special function to send an event - "ecore event info" EO class: an ecore event that carries no info could even use null event info is a base class with a link to its type the loop creates and manages these temporary objects as events are being processed This is consistent with input events (info type are EO objects with a common base class). I see no major issue with this design, besides extra memory requirements. -- Jean-Philippe André ------------------------------------------------------------------------------ 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
