On Mon, 5 Dec 2016 09:53:51 +0900 Jean-Philippe André <j...@videolan.org> said:
> On 4 December 2016 at 11:27, Carsten Haitzler <ras...@rasterman.com> wrote: > > > On Sat, 3 Dec 2016 20:25:46 -0200 Gustavo Sverzut Barbieri < > > barbi...@gmail.com> > > said: > > > > > On Sat, Dec 3, 2016 at 7:13 PM, Vincent Torri <vincent.to...@gmail.com> > > wrote: > > > > On Sat, Dec 3, 2016 at 7:44 PM, Gustavo Sverzut Barbieri > > > > <barbi...@gmail.com> wrote: > > > >> On Sat, Dec 3, 2016 at 1:57 PM, Vincent Torri < > > vincent.to...@gmail.com> > > > >> wrote: > > > >>> Hello > > > >>> > > > >>> I'm rewriting my multi-document viewer. I'm using EFL git, and i > > have > > > >>> that Eo error message : > > > >>> > > > >>> ERR<59568>:eo[T:3] lib/eo/eo.c:1663 efl_isa() Object 40007f56 is not > > a > > > >>> valid object in this context: object domain: 0, current domain: 2, > > > >>> local domain: 2, available domains: [ 1 2 ] > > > >>> > > > >>> does someone have an idea of the problem ? > > > >> > > > >> the new efl in git provides more context to that message since > > > >> yesterday, particularly if you use EO_LIFECYCLE_DEBUG=1 (envvar), > > > >> since I was so pissed with such nebulous messages :-D > > > > > > > > all the debug stuff does not work on Windows (it needs libunwind, or > > > > at least DWARF parsing to get the debug symbols), but i will test on > > > > Linux when I have time. > > > > > > > > i've also seen some preload stuff you mentioned, which does not work > > > > on Windows (it's a different method to do similar stuff) > > > > > > > >> usually the object is already dead or was never created... If you're > > > >> using threads (seems so due "[T:3]"), be aware that objects are bound > > > >> to the thread they were created and you need to "import" to use, > > > >> Raster sent some email to the list and I recall som tests in the > > > >> tree.... > > > > > > > > I indeed use an ecore_thread > > > > > > yes, reading the message again, not just the T:3 for the thread, but > > > also the "object domain: 0" (main thread) while "current domain: 2" > > > (secondary thread) would lead to a failure since raster added the > > > protection. > > > > see the message is NOT nebulous. its giving you details the object belongs > > to > > thread domain 0 but your current domain is 2. thus thread does not belong > > to > > the same thread domain that created the object. domain 1 is the shared > > domain > > so should you see object domain being 1 and it still isn't found that means > > there is no object there at all ion the shared table. > > > > the message is very explicit as to the core details of the issue. it's an > > invalid object as far as the thread accessing it is concerned. > > > > > If you want to use auto-locks, then get the shared domain with: > > > > > > efl_domain_current_push(EFL_ID_DOMAIN_SHARED); > > > my_obj = efl_add(...); > > > efl_domain_current_pop(); > > > > this isn't really an option UNLESS you created the class entirely inherited > > from base class. i.e. the object class doesn't otherwise use any other > > non-threadsafe data outside the object. > > > > > check eo_test_general.c and Eo.h, they can give you an idea of what > > > can you do... basically all objects are bound to one thread (domain), > > > main thread or shared. Their parent must be in the same domain. This > > > allows TLS of eoid stuff, avoiding locks and possibly avoiding > > > concurrency bugs. Just the shared domains have locks as it used to be > > > in the whole eo. > > > > yup. and even creating shared objects comes with limitations. the intent > > is for > > very specialized objects to become shared objects so multiple threads can > > chare > > them. the general idea is you will have very very very few shared > > objects, so > > then the global mutex surrounding all shared objects isn't really a big > > issue,but sometimes sharing an object is far easier and simpler than > > anything > > else, and you are not that concerned about contention and performance. most > > objects will be thread-local (and most efl objects will be main-loop local > > of > > course). > > > > but the error right now is very detailed and tells you exactly what it > > sees is > > probably going wrong in the lookup so you can figure out if its a > > cross-thread > > access problem OR that the object actually does not exist. be aware that > > mainloop domain is 0, and the default domain for ALL other threads is 2. > > that > > means create obj in one non-mainloop thread and access in another > > non-mainloop > > thread ... both objects will have domain 1 BUT will have separate TLS based > > local object tables so the same object may haver the same domain but not be > > accessible across tables (there is a small chance you could get a > > false-positive access, but given i now starts generation counts off at > > random > > values per thread, its highly unlikely to have the same object id AND > > generation count match). > > <https://lists.sourceforge.net/lists/listinfo/enlightenment-devel> > > > > > Nah I totally agree with Vincent that the error message is cryptic. the message before was just "this is an invalid object". try figure out why from that message: ERR("obj_id %p is not a valid object. Maybe it has been freed or does not belong to your thread?", (void *)obj_id); was the object before. well the specific one was an extra error you added in eo_isa. the generic obj pointer is invalid message is: const char *type = "object"; if (obj_id & ((Eo_Id)1 << (REF_TAG_SHIFT - 1))) type = "class"; ERR("EOID %p is not a valid %s. " "EOID domain=%i, current_domain=%i, local_domain=%i. " "EOID generation=%lx, id=%lx, ref=%i, super=%i. " "Thread self=%lu. " "Available domains [%s %s %s %s]. " "Maybe it has been deleted or does not belong to your thread?", (void *)obj_id, type, (int)domain, (int)data->domain_stack[data->stack_top], (int)data->local_domain, (unsigned long)(obj_id & MASK_GENERATIONS), (unsigned long)(obj_id >> SHIFT_ENTRY_ID) & (MAX_ENTRY_ID | MAX_TABLE_ID | MAX_MID_TABLE_ID), (int)(obj_id >> REF_TAG_SHIFT) & 0x1, (int)(obj_id >> SUPER_TAG_SHIFT) & 0x1, (unsigned long)eina_thread_self(), (data->tables[0]) ? "0" : " ", (data->tables[1]) ? "1" : " ", (data->tables[2]) ? "2" : " ", (data->tables[3]) ? "3" : " " ); maybe it should use the generic error print? > Anyway as far as I remember shared objects are not a viable solution until > we change the calling mechanism (function & data resolution) to be > thread-safe, rather than locking the entire pool of shared objects for the > entire duration of a call. locking the whole pool means we can do shared objects without a whole tonne of extra work. as long as all things accessed inside object methods (including parent classes) are entirely within the code for that object or are already threadsafe then no extra locks have to be written at all. everything will just work and it's a massive amount of work saved. having to fine-grain lock everything manually is just insane and that's why efl is not threadsafe and never will be because no one is going to go do that. this is why many libs are not threadsafe. it's a massive amount of work to do and easy to get wrong to miss an lock or unlock somewhere. having a single locking and unlocking spot even if it is a "one big fat lock for every shared object" is safer and far less work. it is unlikely to ever be a real performance issue. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
