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). -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
