On Wed, Apr 13, 2016 at 4:37 PM, Carsten Haitzler <[email protected]> wrote: > 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.
I do not believe it is possible to have a generic threadsafe object in C anyway. You need external synchronisation primitive or you will have race condition when passing parameter and returning value. Some primitive can be threadsafe, but the concept of threadsafety is unlikely to be broad. > simple stuff like i am setting data keys in one thread and getting their value > in another... Will always be a race condition if you don't have any synchronisation primitive between both side. The parameter of your function call and the returned value are always, by construction, outside of any potential lock, making it impossible to be threadsafe. We tried that with ecore and we all know it failed for that exact reason. > 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); This call has no synchronisation issue as long as eo internal code to resolve function is threadsafe, because it doesn't influence the parameter, nor the return value and that's all we need and can do ! Oh, and eo_ref/unref should already be threadsafe, but anyway in the example above, the mainloop should be refcounted when a thread get created and unref when it get destroyed. Otherwise the above code will always be race. > 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). I just don't believe it is doable in any sensible way. Let's take a few example : eo_event_callback_call Where should now the event be triggered ? It can be in the thread where we are calling the function, but then it force the code in that event handler to be thread aware or it will crash. Most people will get that wrong and that will lead to bug. If we force it in the thread owning the Eo object, how can we do that in a sensible way ? Should now Eo always rely on Ecore ? Also this will not work with Ecore_Thread object when we do them, as they will likely have event in both thread... So this is a first example that show how confusing this is going to be. But let's continue with : eo_key_data_set/get/del. So you have one side who does set stuff and the other get stuff... Doesn't work at all, you need a way to be notified of a change. You can't sensibly implement anything by doing a polling. So how do we get a notification, an event every time we set some data ? That's going to be extreme and slow down the default use case which is for non thread safe case. But can we actually do the internal in a thread safe way for a specific object and add that event in that case ? Plus maybe a wait operation. I think it is doable by inheriting the data_set/get/del function and adding the lock + an event emit in the correct thread. That's why I am really not convinced at all that we should increase the cost of our base object for pseudo thread safety as at the end it is doable for specific case in the object themself and in a less confusing way. -- 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
