On Tue, 17 Jan 2012 09:53:15 -0200 Gustavo Sverzut Barbieri
<barbi...@profusion.mobi> said:
> On Tue, Jan 17, 2012 at 8:56 AM, Carsten Haitzler <ras...@rasterman.com>
> wrote:
> > On Fri, 6 Jan 2012 12:34:43 -0200 Gustavo Sverzut Barbieri
> > <barbi...@profusion.mobi> said:
> >
> > finally i'm getting around to this thread...
> >
> > one thing i don't like is passing in all the funcs as params. we did this
> > with smart class. we abandoned it.
> >
> > BUt we should have a elm_genlist_itc_new() (and free()).
> >
> > why? 1. refcounting, 2. handling initializing the struct all to null/0 AND
> > setting a version. (yes we can do it with static/const structs and app sets
> > version so we know struct size base don version num... BUT that doesn't
> > solve the core problem here)...
>
> I've explained this already, you can't convince me. I'm repeating
> again: adding this is asking for trouble, you'll have people to do
> even more mess.
i totally don't see how its asking for trouble. it's a much better way of
managing the setup of methods to call to get item data. using item_del_cb
frankly means the app (or module) has to do all this reference tracking itself.
> > and the CORE problem is... dlclose(). your object has been deleted. done - u
> > dlclose the module it came from.. CRASH. the struct for item class just was
> > ripped out of memory. almost everything else allows the module to remove
> > callbacks and anything that may be called... EXCEPT for this. here the class
> > must stay around in memory - the module can fill func ptr's with NULL to
> > make it save (and make it do nothing) but the class struct must live. i'll
> > send my feedback to hyoyoung's mail. :)
>
> Oh nice! And in what realistic program the pointers stored in this
> struct are not in the dlopen()ed part? Huh? Then you don't crash on
> the struct, but on the symbol! :-(
i think you missed it. the CODe in a dlopened MODULE has a static const
Elm_Genlist_Item_Class itc = {...}; in it. the code in the module creates some
widgets and a genlist... and it registers the pointer to the item class that is
sitting inits mmaped code from the module on disk. the module is shut down but
due to reffing of objects inside callbacks deletions is deferred until after
module is actually unloaded and thus tyhe item class struct pointer points to
memory now unmapped and removed... crash. NOTHING to do with symbols.
without refcounting and duplicating the item class on heap (or stack) this will
always happen as there is no way to exactly know when the item class is
"finally finished with" without refcounting. putting it on the heap makes it
safe to be accessed (and discover func ptrs are NULL) safely no matter what
happened to the dlopen()ed module that the func ptrs originally pointed to.
as it is now, this is not possible. even if we add a version member we STILL
don't know when the item class is finished with. by allocating we get the bonus
of filling in the struct with known values and a known size (to the lib). the
app already can just dumbly fill in fields it knows now and extras added later
are null/0 so its safe and easy for app writer. its also safe for lib at the
same time.
> If you're resetting, just remove the items using it. Same effort. Cleaner.
>
> Anyway, you can't convince me, I can't convince you. You'll get it in
> and help genlist become worse than it already is... I'm giving up on
i don't see how this makes it worse than it is now. in terms of complexity it
actually gets simpler to handle corner cases AND handles forwards compatibility
into the future etc. if you want to use it as its used now u can do:
static Elm_Genlist_Item_Class *itc = NULL;
if (!itc) {
itc = elm_genlist_item_class_new();
itc->func.label_get = mylabelget;
...
}
we just handled versioning there. we can expand the struct in future knowing
new members will be NULL.
if we add the ability for a genlist to reference an item class itself (it keeps
a list of item classes it refs and keeps alive as long as the genlist is alive
like elm_genlist_item_class_register_add(obj, itc); - add a register_del too),
then u can register and immediately unref knowing it will all be cleaned up
for u on object del. the dlclose() of a module making genlists can just null
out all funcs in its item classes on dlclose and "forget about it" safely after
that.
> genlist and if I really care I can try to provide something external
> that does its job and works for me.
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --------------------------------------
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
