unity-dev team mailing list archive

[Michal Hruby <michal.hruby@xxxxxxxxxxxxx>]

On 05/24/2012 06:20 PM, Marco Trevisan (Treviño) wrote:
> 2012/5/24 Mikkel Kamstrup Erlandsen <mikkel.kamstrup@xxxxxxxxxxxxx>:
>
>> 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.
>

I implemented a custom GSource that allows adding of multiple timeouts
to this single source, I profiled this somewhat (against standard
timeout sources) and when using 8 different timeouts, the single custom
source requires 2.5x fewer lock calls (g_mutex_lock), ~6% fewer
instructions are executed and ~10% fewer branches.

Of course there are some drawbacks - timeouts can only be added from the
same thread and it currently uses void* to identify the timeouts
(instead of uint), moreover removing the same timeout multiple times
could be more dangerous. But despite these, I think your branch could
make good use of it (or some variation of it).