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

[jpd at videolan.org]

On Wed, Jun 03, 2009 at 06:51:09PM +0300, R?mi Denis-Courmont wrote:
> Of all options, the accessor is the one that needs the longest source
> code, the largest binary code, occupies to most stack and has the
> worst locality.

Not if you're willing to rely on compiler features, in casu static
inline or for all its faults, perhaps a macro. I for me see more sense
in depending on standard language features over depending on optional
compiler optimisations.


> > None of that is guaranteed, nor knowable without exhaustive survey,
> > and no more than clever clean up after avoidable action. I don't see
> > significant difference in cache line use whether that deref happens
> > before or after the calling branch.
>
> Yes. The cache line use is most certainly irrelevant and the calling
> convention is platform-dependent and hence also mostly irrelevant. But
> so is the extra pointer on the stack.

Except for the minor point that we control the latter and cannot
control any of the former without very specific compiler requirements.


> My first point is: the data pointer is always used currently, and
> likely will almost always be needed. The timer pointer is never
> used currently, although it maybe useful in a few specific cases.

In those specific cases the callee could fetch it from the data pointer
(by callee-specific means, of course). Inconvenient perhaps, but if
it is known to be useful only for a minority of cases, that may be a
reasonable tradeoff.


> My second point is: it is more consistent and conventional
> to give the opaque data (see vlc_clone(), see also the underlying
> implementations);

Or _an_ opaque data pointer somewhere, at any rate. EG kqueue transports
them inside the note struct, which makes sense in context. But yes,
a void * is somewhat traditional.


> if we were to provide only the timer pointer, we should *get rid*
> of the opaque data altogether and use something like Linux kernel's
> container_of or VLC's own vlc_object_internals() and libvlc_priv(),
> but it certainly would be less convenient.

Those look suspiciously like they perform the function of an accessor to
a more-or-less type checked user cookie from here, BICBW.

I don't see how basically replacing

  struct mystruct *realdata = (struct *mystruct)data;

with

  struct mystruct *realdata = the_appropriate_accessor(timer);

would be less convenient?