unity-dev team mailing list archive

[Marco Trevisan (Treviño) <3v1n0@xxxxxxxxxx>]

2012/5/24 Mikkel Kamstrup Erlandsen <mikkel.kamstrup@xxxxxxxxxxxxx>:
> On 05/23/2012 09:38 PM, Marco Trevisan (Treviño) wrote:
> Currently glib::Source is very simple and I've only designed it to
>> wrap the glib struct, but probably we could improve that also to be
>> reused.
>
> If we actually use that many you might try to reduce memory fragmentation by
> making the glib::Source class castable to a GSource (ie. by having a GSource
> value as the first member in the struct). Or if glib::Source is primarily
> stack allocated this doesn't matter, of course.

glib::Source's are mostly heap allocated... I could make them
wrappable to a GSource* with some changes, but is this really
improving a lot the things, construction and destruction of the
wrapper and the wrapped objects should mostly happen at the same time
there.

> Considering "reuse" of sources I am not sure I like the word "reuse" since
> that seems something that could be error prone. I'd rather see it done by
> using some (thread safe) global static sources that we attach closures to so
> to say.
>
> For example - I don't see any particular reason that one would ever need
> more than one timeout source in an entire app lifetime. There could be one
> global timeout source that managed a (sorted) list of timeout closures.
>  Same goes for idle sources in fact.

Yes, that's the same thing I meant... Having an our class that handles
most of timeouts into the unity code could just help in future to
switch to that, just acting on that class instead of refactoring the
current code.

-- 
Treviño, Ubuntu member
https://launchpad.net/~3v1n0
http://www.3v1n0.net