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. 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. Best regards, -- Jean-Philippe André ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
