On Sun, 24 Dec 2017 09:23:16 +0000 Andrew Williams <a...@andywilliams.me> said:
> Hi,
>
> Yes invalid access is easier to debug than a memory lean, in general.
> In this situation we are talking about the possible consistent memory leaks
> vs the occasional (race condition) undefined access. The latter is not
> easier to debug.
you just said it was easier to debug, then you say it isn't... eh? and you
agree with me that leaks will be more common than invalid accesses, yet you
want to propose a method that has a greater percentage of problems (and i
argue a greater consequence when those issues arise).
> And if we did find the line at error it would look (using the designed
> efl_add behaviour) completely reasonable - what would the fix even be?
the fact a parent has deleted an object "unexpectedly" is the issue. why is it
unexpected? you do this:
obj = efl_add(class, parent);
efl_del(parent);
efl_method_x(obj); // invalid access here
it'll be an invalid object access. well obviously. parent deleted it's child. i
would not class this as unexpected. if it's defined behaviour like
obj = efl_add(class, parent);
efl_do_something_abort(parent);
efl_method_x(obj); // invalid access here
then doing "so_something_abort" on the parent causes children to be deleted.
maybe it was a bad choice to have this kind of behaviour? perhaps it is the
right thing? check the api docs.
but in the C language SCOPE does NOT guarantee a reference to an object because
C has no such scoping rules. just because i have a struct x * in my scope
doesn't mean something might not free it while i am running. it is no js or c#
or java etc. ... it's C. even C++ doesn't guarantee this unless you explicitly
use an RAII pattern. This is the nature of the language. trying to force other
language models on it will lead to more verbose code, with manual need to
remember to unref and thus more likely chances of things going wrong. i'm
repeating myself.
but still. the vast majority of developers disagree with you. your proposal is
to have to unref a handle if you want to have a handle to do something with it
which is exactly what was voted on. if *YOU* wish to do this... it exists.
efl_add_ref(). most developers disagree with you and would advise against. that
still doesn't even address the fact that a change at this stage to what you
propose would be insanely disruptive to the efl tree, development in general
and lead to bugs needing to be cleaned up for the next 6-12 or even more months
as a result of it. but the decision was made with a vastly overwhelming
majority disagreeing with you. your "but they didn't consider null parents" is
bogus. of course null parents are considered because they HAVE to be to create
toplevel objects anyway. your proposal means needing efl_add_ref whenever you
need the obj handle and that was voted on as "bad".
> Andy
>
> On Sun, 24 Dec 2017 at 03:33, Carsten Haitzler <ras...@rasterman.com> wrote:
>
> > On Sat, 23 Dec 2017 11:19:59 +0000 Andrew Williams <a...@andywilliams.me>
> > said:
> >
> > > As framework developers we should be doing everything in our power to
> > avoid
> > > undefined behaviour. I’ll take accidents memory leaks any day - there
> > are a
> > > plethora of tools to solve that but it’s far harder to debug the “app not
> > > working correctly sometimes on my system” bug reports.
> >
> > actually no. we should be doing everything we can to make things EASY.
> > avoiding
> > undefined behaviour is one way of making things easier. having to write
> > less
> > code and it be HARDER to write things that have bad side-effects is also
> > making
> > things easier.
> >
> > if you don't leak large amounts of objects you will not have tools find it
> > easy
> > to find such leaks. if you leak LOTs (1000's or more objects in one place)
> > then
> > you can probably find it by spotting an excessive allocation point in
> > something
> > like massif, BUT nothing will detect a leaked pointer, because eoid
> > maintains a
> > pointer to the object in the eoid object table. the pointer is actually
> > never
> > lost. it's tracked by eo. so no. leak check tools won't work. maybe "still
> > allocated on shutdown" might unless you have a LOT of that data which is a
> > lot
> > of work to ensure is done. there are lots of allocations on exit from efl,
> > glibc and other places already (that are harmless).
> >
> > invalid access as i explained is directly ind immediately debuggable.
> > leaks -
> > not so much.
> >
> > but regardless of that the votes already were vastly for the thing we have
> > today.
> >
> > > Andy
> > >
> > > On Sat, 23 Dec 2017 at 10:56, Carsten Haitzler <ras...@rasterman.com>
> > wrote:
> > >
> > > > On Fri, 22 Dec 2017 11:53:32 +0000 Andrew Williams <
> > a...@andywilliams.me>
> > > > said:
> > > >
> > > > > We do have a showstopper design bug.
> > > >
> > > > see my previous mail. https://phab.enlightenment.org/V7 to be
> > explicit.
> > > > discussed. voted on. known compromise. lots of code built on top of
> > that
> > > > design
> > > > decision. not a showstopper by any stretch. it's exactly what gtk
> > does. the
> > > > only difference is we have the "parent set" be part of the add and gtk
> > > > does it
> > > > as a separate step with container_add()
> > > >
> > > > > We are managing to work with it because we know how it works
> > internally.
> > > > > The API must be straight forward and provide consistent, robust
> > options.
> > > > >
> > > > > Any new user would be asking of efl_add:
> > > > > *) Do I need to unref the result when I am done?
> > > > > *) How long is my returned reference valid for?
> > > >
> > > > see the vote. see gtk samples. floating reference.
> > > >
> > > > > Both of those are answered with "it depends" and that is a design
> > > > > showstopper.
> > > >
> > > > disagree. it's clear. if parent is NULL then calling scope gets a
> > > > floating reference you have to unref. if not then parent owns that
> > > > reference and the rules of that parent cover lifetime of that object.
> > > > covered
> > > > that in prior mails - the alternative is to force people to manually
> > unref
> > > > every time they want a handle to something at all to do useful things
> > with
> > > > ...
> > > > like add a child to this parent (child packed into a box parent for
> > > > example).
> > > > see the gtk/gobject design doc with the idea of floating references.
> > see
> > > > the
> > > > previous discussion thread. see the vote in favor of what is there now
> > and
> > > > with
> > > > everyone fully aware of scoping etc. and that is why efl_add_ref
> > exists if
> > > > you
> > > > choose to use that.
> > > >
> > > > note for this discussion i am assuming scope is a small local function
> > > > scope
> > > > not larger. technically it can be the global scope of the entire app.
> > > >
> > > > i'll put it simply:
> > > >
> > > > 1: do it your way and people will have to always unref at end of scope
> > (if
> > > > they
> > > > want an object handle to do something with, like pack a button into a
> > box
> > > > parent which is exceedingly common). the will at times forget to unref
> > > > causing
> > > > leaks.
> > > >
> > > > 2: do it the current way and perhaps sometimes in some rare
> > circumstances
> > > > an
> > > > object is deleted by a parent before your scope ends.
> > > >
> > > > chances of 1: i'll put it at maybe 10-20% that someone forgets a scope
> > > > exit case
> > > > and forgets to unref (a return in the middle for example).
> > > >
> > > > chances of 2: i'll put at at maybe 1% on a bad day. likely far far
> > less.
> > > >
> > > > so let's say 15% to 1%. 15x more mistakes likely with your proposal.
> > but
> > > > let's
> > > > cover the CONSEQUENCES of a mistake:
> > > >
> > > > consequences of 1: leak memory (possibly huge amounts, if for example
> > this
> > > > is
> > > > inside a model where you create objects and return them to the model to
> > > > display but now they return with an extra ref and never get deleted as
> > a
> > > > result). leaking enough memory will result in severe system degradation
> > > > (hitting swap or OOM killer) not to mention be relatively hard to pin
> > down
> > > > where the extra ref came from. a lot of fun debugging this ans
> > isolating
> > > > it.
> > > >
> > > > consequences of 2: a complaint to stderr with the object id, a
> > backtrace to
> > > > where it's invalid (instantly identifying the point of invalid access
> > and
> > > > very
> > > > quickly leading to finding the source). with the identification of the
> > > > invalid
> > > > source point, finding the deletion point is very easy by adding a del
> > event
> > > > callback and tracing that. We could find ways of making this easier
> > with
> > > > env
> > > > vars or a convenience call like efl_debug_del_track(obj, EINA_TRUE)
> > which
> > > > might print a debug log with bt on deletion of this object. you already
> > > > know
> > > > the exact object that is creating this issue from the first bt... so
> > this
> > > > will
> > > > be a 2nd step to isolate it exactly. much easier to fix than #1 AND the
> > > > conseqeunces are far less as it's just a "error print".
> > > >
> > > > so how do we rate the conequences? well #2 - let's call it a 10, and
> > let's
> > > > say
> > > > somethnig vey hard to debug and that could lead to oom killers and swap
> > > > storms... i'll call that a 1000. so 15*1000 vs 1*10. 1500 TIMES worse.
> > yes.
> > > > numbers pulled out of thin air. i'm making a point. your proposal is
> > worse.
> > > >
> > > > in addition moving from #2 to #1 would be a huge effort to do, lead to
> > a
> > > > lot of
> > > > problems in the efl tree for a long time until cleaned up (leaks found
> > and
> > > > fixed, all the instances done right etc.) thus adding pain, delays etc.
> > > > etc.
> > > > and ... who will do it? the majority (~87% of devs) disagree with it
> > > > option #2.
> > > > see poll. so most devs will not be keen to do something the vast
> > majority
> > > > disagree with.
> > > >
> > > > is something voted against by 87% of devs and 1500 times worse for the
> > end
> > > > user worth spending a lot of effort on and adding delays and such pain?
> > > >
> > > > > Andrew
> > > > >
> > > > > On Fri, 22 Dec 2017 at 10:56 Carsten Haitzler <ras...@rasterman.com>
> > > > wrote:
> > > > >
> > > > > > [snip]
> > > > > >
> > > > > > this is the kind of change that would only really justify being
> > done
> > > > if we
> > > > > > had
> > > > > > a showstopper design bug. we do not. not IMHO. there is clear
> > > > behaviour and
> > > > > > it's logical and simple. if you don't LIKE it... efl_add_ref is
> > there
> > > > for
> > > > > > you
> > > > > > to use and then to remember to unref on all scope exits by hand. i
> > > > > > certainly
> > > > > > would not choose to use this.
> > > > > >
> > > > > > [snip]
> > > > > >
> > > > > > --
> > > > > > ------------- Codito, ergo sum - "I code, therefore I am"
> > > > --------------
> > > > > > Carsten Haitzler - ras...@rasterman.com
> > > > > >
> > > > > > --
> > > > > http://andywilliams.me
> > > > > http://ajwillia.ms
> > > >
> > > >
> > > > --
> > > > ------------- Codito, ergo sum - "I code, therefore I am"
> > --------------
> > > > Carsten Haitzler - ras...@rasterman.com
> > > >
> > > > --
> > > http://andywilliams.me
> > > http://ajwillia.ms
> >
> >
> > --
> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > Carsten Haitzler - ras...@rasterman.com
> >
> > --
> http://andywilliams.me
> http://ajwillia.ms
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
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
