On Sat, 3 Sep 2016 23:06:09 -0300 Felipe Magno de Almeida <felipe.m.alme...@gmail.com> said:
> On Sat, Sep 3, 2016 at 12:15 PM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > Why? This directly impacts design and limitations of EO. It also impacts > > performance. It also impacts safety. This is rather important to settle for > > 1.19 as this lays the base for the future of EFL. > > [snip] > > > > Object *obj = all_eo_objects[eoid]; > > Should the table of tables ever free tables? Why do I ask that? well it does, but this is an implementation detail and allocation policy issue. if we had some amount odf "garbage" space we waste to avoid reallocation than that gets over most of it. i wouldnt ever have a "never free" policy tho. just defer it. > Because the number of Eo_Ids should become stable and > actually spending time freeing for later allocating again seems > wasteful. But even more importantly, it would be possible > for me to implement a lock-free table. it'd be a waste of memory though. if you baloon out and suddenly create 100k objects, then go back to 2k - we'd be throwing away 1.6m. > The idea of TLS is not a bad idea anyway, because it avoids > cache thrashing and is an interesting idea for safe-guarding > non-thread-safe objects. However, TLS tables would need that's actually what attracts me to the idea. it solves an issue AND adds safety. we could go for the "never free" method for a "shared object table" only as well, but we'd still need locks fo the eoid cache that cedric added recently. > deallocation because threads come and go and might > just create thousands of objects, moving them to another > thread and then just stay idle waiting for events for hours, > wasting a lot of memory in the table. yup. > However, having thread-safe objects through a lock-free table > could still be very valuable, IMO and not freeing entry tables > from Eo_Id table seems like a very reasonable compromise. i'm thinking this might be good for the future. i can see the benefit. it'd be a lot more work now. right now i think it's important to figure out if we want to do tls at all or not, then explore "on paper" some other ideas like a shared eoid table that may be "never free" like you say or its the only one with locks (thus there is a cost for these objects... but ONLY these). we need to imagine designs and implementations for these things we will do in future (or might) and make sure we haven't designed something that makes it impossible (without breaking api/abi). so i'm beginning to like at least 1 "shared table" with 1 "eoid domain" devoted to it and other domains all kept private to their thread and only shared out WHILE the onwer is locked out safely from execution. to do shared later we have to allocate off 1 domain for use for that now, and ensure we can detect a shared obj in future and do a recursive mutex take and release on it (eina mutexes are not recursive - there's a comment that this breaks on/off - what on earth is that?). so if we can portably do recursive mutexes then we could have eo auto-lock the obj on entry, auto release on return, and if eoid domain == shared domain do the lock on the shared table and the unlock etc. etc. - in fact maybe this is easier than i thought ... but we still need to determine WHICH domain an obj belongs to at creation. that may affect our API right now. i.e. eo_add. this will also have implications for bindings like c++. > [snip] > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > Regards, > -- > Felipe Magno de Almeida > > ------------------------------------------------------------------------------ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- 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
