Le mercredi 26 novembre 2014 à 20:01 +0900, Carsten Haitzler a écrit : > On Wed, 26 Nov 2014 11:40:01 +0100 José Bollo <[email protected]> > said: > > > Hi all, > > > > Congratz to you Carsten for "putting the feets in the > > course" (translation of a french expression meaning "going into > > embarassant discussion"). That is great to read! And I fully agrre with > > you that there is something weird. > > > > However, (please, correct me if I'm wrong) there is at least one > > recurring problem with event loops when your are using libraries (like C > > API of tizen 2.3 native progtramming libraries) that should access > > ressources provided by an event loop. > > > > These libraries don't know what is the event loop you chosen. It rather > > use an event loop API and expects that it works. There is no cool > > solution to solve this problem. A common solution is to use the GLIB > > event loop primitive while providing a GLIB loop integration in common > > event loops, like in ecore. > > that is one way. but it is a fairly big assumption to assume there is alwasy a > glib mainloop. efl has it as a build option, but it's not guaranteed. there is > a call -> ecore_main_loop_glib_integrate() that returns true if glib is > integrated (at runtime) and false otherwise. (it will also enable integration > if not aleady enabled). this only will work if it's compiled with the support > though. it'd always fail (return false) if not. at least libraries can detect. > > there are some gotchas. for example efl has things like ecore_poller()s. these > are intended for polling and minimizing wakeups .. if this is needed. they can > be allowed to be "fuzzy" - eg not go off at an exact time and instead be > deferred until some more desired time. efl can automatically mess around with > these, but it can't do anything with glib. > > efl has animators (last i knew glib didn't). these are callbacks that are > called "per frame". when they are called may vary on vsync (if screen is 70hz, > animators go off at 70hz - exactly at vblank interrupt time with the ecore > mainloop "wakeup timepoint" set to EXACTLY the time when the hardware > interrupt > fired to generate the vblank interrupt, even if called later). if glib is used > then you totally drop the support for vsync based animation for example. > > efl also has thread marshalling constructs that handle a thread worker pool > for > you and marshal results back to the mainloop calling their callbacks there > (makes it really easy to isolate thread work and cleanly get results without > nasty locks everywhere). also stuff like locks on the mainloop, so if you have > a thread that needs to do things to the ui (or whatever) in the mainloop, and > you don't want to handle async marshallling of results back, but want to > implement the results "inline" you can do an ecore_thread_main_loop_begin() > and > ecore_thread_main_loop_end() around your critical section to ensure you have a > lock on the mainloop for those lines of code. > > there are a whole bunch of other mainloop callback constructs in efl that > don't > exist in glib (last i knew - correct me if i'm wrong), like idle enterers and > exiters (glib has idlers to call while idling in a tight loop). > > so assuming glib as the mainloop will limit what you can do by a fair degree > (and cause you to likely re-invent some of the above yourself in your code, or > simply be unable to do things like the mainloop lock begin/end from a thread).
I agree that from your description, efl has many advantages. Using glib implies the greatest common denominator that is not much. > so we could assume glib as a base - but then it comes with the above problems > at a minimum. and yes - i agree that it is a problem for apps and all the > libraries to not know what their mainloop infra is and depend on it (and > re-use > it as much as possible to save code/effort and behave as well as possible). Yes, being agnostic, refusing to choose are some of the drawbacks of using linux. For example: "Q: Do you know libevent? I believe that it is used in chromium. A: What? Oh yes! It's just <<yet another dispatch loop....>>" Hum, I'm discouraged and frustrated by this state. Not for the same reasons than you, of course ;) What would be good is a libc or linux proposal for solving that problem. But the legacy would break such idea anyway... Best regards José _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
