[vlc-devel] commit: Asynchronous timer API ( R??mi Denis-Courmont )

[jpd at videolan.org]

On Wed, Jun 03, 2009 at 01:02:22PM +0200, R??mi Denis-Courmont wrote:
> On Wed, 3 Jun 2009 12:45:10 +0200, jpd at videolan.org wrote:
> > On Tue, Jun 02, 2009 at 08:32:09PM +0200, git version control wrote:
> >> +struct vlc_timer_t
> >> +{
> >> +    timer_t handle;
> >> +    void (*func) (vlc_timer_t *, void *);
> >> +    void *data;
> >> +};
> > 
> > Why func(vlc_timer_t, data) instead of just func(vlc_timer_t) and
> > expecting func to say vlc_timer_t->data?
> 
> Because this is ugly. I could live with removing the timer, but removing
> the opaque data seems wrong.

The point is that the opaque data is already in the timer passed, so
you're merely doing a deref on behalf of the client whether it needs it
or not. I don't agree on your assessment of ugly here, though. Opaque
cookie pointers tend to get treated this way:

  void func0(vlc_timer_t *timer, void *data)
  {
    realstruct *realdata = (mystruct *)data; /* last time we use data */
    ...
  }

versus

  void func1(vlc_timer_t *timer)
  {
    realstruct *realdata = (mystruct *)timer->data;
    ...
  }

Passing two arguments doesn't seem to add substance, in fact the extra
void * is effectively dead space on the stack. To me one argument,
either one, would be enough, but I'd likely choose the timer one all the
same.

Passing vlc_timer_t * allows the callee to modify timer->data, (and
the rest of the timer struct) so if that is a problem then pass only
the void * cookie. Or maybe make the timer const and document that Bad
Things Will Happen when casting away constness.


> > As a sidenote, some systems have hard limits on the number of timers one
> > can create (and the system might fail in Interesting Ways should that
> > limit be reached). I don't know what order of number of timers vlc would
> > like to use, but do we have fallbacks for the less time critical timer
> > users?
> 
> A timer requires fewer resources than a permanent thread, which is what we
> had earlier.

One permanent thread for all timers still beats using many timers in
terms of resource pressure. Of course it would be simpler to not care,
but how many timers does a random vlc chain use?