Re: [E-devel] Eo error message in my application

[The Rasterman]

On Mon, 5 Dec 2016 11:33:13 -0200 Felipe Magno de Almeida
 said:

> On Mon, Dec 5, 2016 at 12:04 AM, Carsten Haitzler 
> wrote:
> > On Mon, 5 Dec 2016 09:53:51 +0900 Jean-Philippe André 
> > said:
> 
> [snip]
> 
> >> 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.
> 
> I don't care about the performance. This is going to be a deadlock hell.

you're going to have deadlocks with fine grained locking too. deal with it.
it's part of life with locking and threads unless you design very carefully.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo error message in my application

[The Rasterman]

On Mon, 5 Dec 2016 12:04:26 +0900 Jean-Philippe André  said:

> On 5 December 2016 at 11:04, Carsten Haitzler  wrote:
> 
> > On Mon, 5 Dec 2016 09:53:51 +0900 Jean-Philippe André 
> > said:
> >
> > > On 4 December 2016 at 11:27, Carsten Haitzler 
> > 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
> > > > > >  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 

Re: [E-devel] Eo error message in my application

[The Rasterman]

On Mon, 5 Dec 2016 11:35:34 -0200 Felipe Magno de Almeida
 said:

> On Mon, Dec 5, 2016 at 12:04 AM, Carsten Haitzler 
> wrote:
> > On Sun, 4 Dec 2016 23:23:39 -0200 Felipe Magno de Almeida
> >  said:
> >
> >> On Dec 4, 2016 10:55 PM, "Jean-Philippe André"  wrote:
> >>
> >> 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.
> >>
> >>
> >> Indeed. just like we discussed in Korea. the recursive mutex must go.
> >
> > i then invite you to actually implement all the fine-grained locks for every
> > class and object now and into the future and never to get it wrong. are you
> > going to do that?
> 
> Good point. I'll see what I can do. I would like to implement the multiple
> loops and threading anyway, with the design we discussed. This seems
> to be a part of this work.

We also always have the option of sending objects from thread/loop to thread.
as long as the object has no links to other objects (references or children
etc.) then it's easy. this honestly would be the fast path. shared objects are
a slow path.

keep in mind that mutexes, spjnlocks and even atomic instructions are SLOW
PATHS in a cpu. they take a LOT longer to execute than a normal "instruction"
or even smallish function that they should be. They have to put in memory
barriers and force cache synchronization between cores etc. so shared objects
being "heavy when there is contention" is pretty normal. in fact a single lock
on entry and unlock on exit is about as efficient as can be done. remember you
can do_super() and access other objects, children and parents and so on so
having a single recursive mutex frankly was the sanest thing i could think of
that balanced simplicity, ease of maintainability into the future (having to by
hand put in locks in every method call is going to be nuts and having to have
shared vs non-shared versions of base class etc.). thinking about all the work
needed for fine-grained locking just made me do it this way. this way at least
you DON'T every have to write locking code. simply declare your object as
shared on creation. of course the class has to be sharing-friendly but this is
the same with or without fine grained locks. :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo error message in my application

[The Rasterman]

On Mon, 5 Dec 2016 04:10:49 +0100 Vincent Torri  said:

> i still don't know how to fix the problem...

you need to know where the access is. using EINA_ERROR_ABORT=1 will at least
work on window as get you a backtrace to it... the reasons are either an
invalid object id or access an object across threads.

> On Mon, Dec 5, 2016 at 3:04 AM, Carsten Haitzler  wrote:
> > On Mon, 5 Dec 2016 09:53:51 +0900 Jean-Philippe André 
> > said:
> >
> >> On 4 December 2016 at 11:27, Carsten Haitzler  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 
> >> > wrote:
> >> > > > On Sat, Dec 3, 2016 at 7:44 PM, Gustavo Sverzut Barbieri
> >> > > >  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 

Re: [E-devel] Eo error message in my application

[Felipe Magno de Almeida]

On Mon, Dec 5, 2016 at 12:04 AM, Carsten Haitzler  wrote:
> On Sun, 4 Dec 2016 23:23:39 -0200 Felipe Magno de Almeida
>  said:
>
>> On Dec 4, 2016 10:55 PM, "Jean-Philippe André"  wrote:
>>
>> 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.
>>
>>
>> Indeed. just like we discussed in Korea. the recursive mutex must go.
>
> i then invite you to actually implement all the fine-grained locks for every
> class and object now and into the future and never to get it wrong. are you
> going to do that?

Good point. I'll see what I can do. I would like to implement the multiple
loops and threading anyway, with the design we discussed. This seems
to be a part of this work.

> --

Regards,
-- 
Felipe Magno de Almeida

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo error message in my application

[Felipe Magno de Almeida]

On Mon, Dec 5, 2016 at 12:04 AM, Carsten Haitzler  wrote:
> On Mon, 5 Dec 2016 09:53:51 +0900 Jean-Philippe André  
> said:

[snip]

>> 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.

I don't care about the performance. This is going to be a deadlock hell.

> --

Regards,
-- 
Felipe Magno de Almeida

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo error message in my application

[Vincent Torri]

ok, i've fixed my problem, thank you

Vincent

On Mon, Dec 5, 2016 at 4:10 AM, Vincent Torri  wrote:
> i still don't know how to fix the problem...
>
> On Mon, Dec 5, 2016 at 3:04 AM, Carsten Haitzler  wrote:
>> On Mon, 5 Dec 2016 09:53:51 +0900 Jean-Philippe André  
>> said:
>>
>>> On 4 December 2016 at 11:27, Carsten Haitzler  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 
>>> > wrote:
>>> > > > On Sat, Dec 3, 2016 at 7:44 PM, Gustavo Sverzut Barbieri
>>> > > >  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 

Re: [E-devel] Eo error message in my application

[Vincent Torri]

i still don't know how to fix the problem...

On Mon, Dec 5, 2016 at 3:04 AM, Carsten Haitzler  wrote:
> On Mon, 5 Dec 2016 09:53:51 +0900 Jean-Philippe André  
> said:
>
>> On 4 December 2016 at 11:27, Carsten Haitzler  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 
>> > wrote:
>> > > > On Sat, Dec 3, 2016 at 7:44 PM, Gustavo Sverzut Barbieri
>> > > >  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 

Re: [E-devel] Eo error message in my application

[Jean-Philippe André]

On 5 December 2016 at 11:04, Carsten Haitzler  wrote:

> On Mon, 5 Dec 2016 09:53:51 +0900 Jean-Philippe André 
> said:
>
> > On 4 December 2016 at 11:27, Carsten Haitzler 
> 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
> > > > >  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 

Re: [E-devel] Eo error message in my application

[The Rasterman]

On Sun, 4 Dec 2016 23:23:39 -0200 Felipe Magno de Almeida
 said:

> On Dec 4, 2016 10:55 PM, "Jean-Philippe André"  wrote:
> 
> 
> 
> 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.
> 
> 
> Indeed. just like we discussed in Korea. the recursive mutex must go.

i then invite you to actually implement all the fine-grained locks for every
class and object now and into the future and never to get it wrong. are you
going to do that?

-- 
- 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

Re: [E-devel] Eo error message in my application

[The Rasterman]

On Mon, 5 Dec 2016 09:53:51 +0900 Jean-Philippe André  said:

> On 4 December 2016 at 11:27, Carsten Haitzler  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 
> > wrote:
> > > > On Sat, Dec 3, 2016 at 7:44 PM, Gustavo Sverzut Barbieri
> > > >  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).
> > 

Re: [E-devel] Eo error message in my application

[Felipe Magno de Almeida]

On Dec 4, 2016 10:55 PM, "Jean-Philippe André"  wrote:



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.


Indeed. just like we discussed in Korea. the recursive mutex must go.

Best regards,

--
Jean-Philippe André

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Regards,
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo error message in my application

[Jean-Philippe André]

On 4 December 2016 at 11:27, Carsten Haitzler  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 
> wrote:
> > > On Sat, Dec 3, 2016 at 7:44 PM, Gustavo Sverzut Barbieri
> > >  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).
> 
>


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 

Re: [E-devel] Eo error message in my application

[The Rasterman]

On Sat, 3 Dec 2016 20:25:46 -0200 Gustavo Sverzut Barbieri 
said:

> On Sat, Dec 3, 2016 at 7:13 PM, Vincent Torri  wrote:
> > On Sat, Dec 3, 2016 at 7:44 PM, Gustavo Sverzut Barbieri
> >  wrote:
> >> On Sat, Dec 3, 2016 at 1:57 PM, Vincent Torri 
> >> 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

Re: [E-devel] Eo error message in my application

[Gustavo Sverzut Barbieri]

On Sat, Dec 3, 2016 at 7:13 PM, Vincent Torri  wrote:
> On Sat, Dec 3, 2016 at 7:44 PM, Gustavo Sverzut Barbieri
>  wrote:
>> On Sat, Dec 3, 2016 at 1:57 PM, Vincent Torri  
>> 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.

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();

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.




-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

--
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

Re: [E-devel] Eo error message in my application

[Vincent Torri]

On Sat, Dec 3, 2016 at 7:44 PM, Gustavo Sverzut Barbieri
 wrote:
> On Sat, Dec 3, 2016 at 1:57 PM, Vincent Torri  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

Vincent

> which reminds me that my EO_LIFECYCLE_DEBUG doesn't cover the
> domain... maybe it should.
>
> --
> 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

--
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

Re: [E-devel] Eo error message in my application

[Gustavo Sverzut Barbieri]

On Sat, Dec 3, 2016 at 1:57 PM, Vincent Torri  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

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

which reminds me that my EO_LIFECYCLE_DEBUG doesn't cover the
domain... maybe it should.

--
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

[E-devel] Eo error message in my application

[Vincent Torri]

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 ?

thank you

Vincent

--
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