On 11/26/2014 08:52 PM, José Bollo wrote: > 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....>>"
yeah. there is no standard we all agree on. if there was a standard event loop at the libc level - then we'd all use it. instead everyone makes a new one. the slight problem is that each event loop lib in the past prettymuch also comes with a bunch of baggae too - eg data structures and other utilities too. and thats when peole begin to disagree. the best we can do is that if you make a 3rd party lib - make sure it CAN be integrated into an event loop. it's the job of whoever uses that lib to integrate it. a bunch of bits of efl do exactly this - they "wrap" a lib and integrate it into the mainloop. the lib is still used, just efl providing the integration and marshaling. i suspect this kind of solution is the best option we have. as for apps - they will need to integrate into some mainloop - they need to assume one somewhere and i guess.. whatever mainloop the native api provides is the one they can assume. well if it's explicitly documented/exposed. the only one i know that is exposed like that is the efl one (as it is necessary for use with efl). > 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é -- The above message is intended solely for the named addressee and may contain trade secret, industrial technology or privileged and confidential information otherwise protected under applicable law including the Unfair Competition Prevention and Trade Secret Protection Act. Any unauthorized dissemination, distribution, copying or use of the information contained in this communication is strictly prohibited. If you have received this communication in error, please notify the sender by email and delete this communication immediately.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
