On Wed, 13 Apr 2016 11:16:58 -0700 Cedric BAIL <[email protected]> said:
> On Wed, Apr 13, 2016 at 3:47 AM, Carsten Haitzler <[email protected]> > wrote: > > i'm wondering... shouldn't we make eo and eo base "threadsafe". ie a basic > > eo object should have locks around things like: > > I am not to sure of the intended idea of making eo threadsafe for all > of those function. If you are using the same object from two > differents thread, it is pretty certain in my opinion that you will > need to have lock to manage its use yourself or you will end up with > crash. I don't think it is possible to build a threadsafe and safe to > use API that won't require the user of that API to actually think > about where to put lock. So if we advertise our API as threadsafe and > the developer don't understand the limit of it (Like most Java > developers for example), he will manage to have race condition and > blame Eo for not being properly threadsafe. I believe it will result > in a more complex use of eo, when can I rely on it being threadsafe, > when can't I ? Which is why I don't think this is a good idea. you CANNOT build a threadsafe object ever if the base class isn't threadsafe. i can NEVER do it. it's impossible to do. simple stuff like i am setting data keys in one thread and getting their value in another... i'm not saying to make all of efl threadsafe. but base class and core eo stuff like the object table have to be to allow someone to build threadsafe objects on top. we already want to make the main loop "thread safe" in that one thread will mainloop.begin(); or efl_loop_beging(mainloop); to do the current ecore_main_loop_begin(); stuff - this involves having calls safe to call from another loop. making the object already threadsafe for these reasons. we are not going to do ALL objects - you can't sensibly go mess with anything ui related from another loop and expect things to work well because a ui tree is in an unknown state when the owning loop comes to render (you need the above begin/end locks). > -- > Cedric BAIL > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications Manager > Applications Manager provides deep performance insights into multiple tiers of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
