i still don't know how to fix the problem... On Mon, Dec 5, 2016 at 3:04 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > 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
------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
