On Fri, 5 Jan 2018 10:53:46 -0200 Gustavo Sverzut Barbieri <barbi...@gmail.com> said:
> On Fri, Jan 5, 2018 at 4:04 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > > raster pushed a commit to branch master. > > > > http://git.enlightenment.org/core/efl.git/commit/?id=76b837002eaea56b5ecb174bffe284012084dc74 > > > > commit 76b837002eaea56b5ecb174bffe284012084dc74 > > Author: Carsten Haitzler (Rasterman) <ras...@rasterman.com> > > Date: Fri Jan 5 15:01:02 2018 +0900 > > > > efl loop - provide efl namespace versions of begin/end locks on mainloop > > > > add efl_main_loop_steal() and efl_main_loop_release() for new efl > > namespace versiosn of ecore_thread_main_loop_begin() and > > ecore_thread_main_loop_end(). > > > +EAPI int > > +efl_main_loop_steal(void) > > +{ > > + return ecore_thread_main_loop_begin(); > > +} > > + > > +EAPI int > > +efl_main_loop_release(void) > > +{ > > + return ecore_thread_main_loop_end(); > > +} > > since we're targeting multi loop and all, this construct in the new > API should be multi-loop as well, that is we should have: we can't do this multi-loop because this is also tied specifically to switching eo domain id's from "thread" to "main" and back. main has one and only one instance - the mainloop eo id. thread is a thread-local per thread domain so you can't actually switch to another thread's domain ... except the main loop. that's why this is like it is ... :) the "lack of being symmetrical for loops" irked me but it's an necessary evil unfortunately. instead for loop to loop i think i'd encourage "sync/async func call" api stuff that's on the todo. see https://phab.enlightenment.org/T5522 it has a lot more details in the todo now. btw i was wanting to talk about the whole reader/writer stuff using in efl.net as i am going to have to have a similar io interface from parent to child loop and back (and also between loops object siblings etc.) the whole buffered binbuf slice etc. thing just seems like overly complex work/effort for just sending a buffer and getting a buffer of bytes to/from a target object. :( what do you think? > efl_loop_steal(loop); > efl_loop_release(loop); > > btw, these names are confusing... I like the old ecore version better, > something like: well begin i thought i'd steer clear from because it gets confused with ecore_main_loop_begin() so easily... :( this realyl does steal the mainloop (steals a lock then releases it as well as stealing the eoid context). > efl_loop_thread_usage_begin(loop); > efl_loop_thread_usage_end(loop); > > or my preference: > > efl_loop_thread_pause(loop); > efl_loop_thread_resume(loop); indeed it pauses and resumes... but it ALSO "steals" the eoid context from the mainloop so your code after the steal acts as if it were in the mainloop eoid context (it can access mainloop eo objects now). > anyway, if by final EO api release we still offer efl_main_loop > helpers (I think we shouldn't!), then you can offer your helpers on > top of that. see above... can't actually do it loop by loop. :( > -- > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com ------------------------------------------------------------------------------ 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
