ok, i've fixed my problem, thank you Vincent
On Mon, Dec 5, 2016 at 4:10 AM, Vincent Torri <vincent.to...@gmail.com> wrote: > 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
