lkml.org 
[lkml]   [2006]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] timers, pointers to functions and type safety
    On Sat, Dec 02, 2006 at 11:13:21PM +0100, Roman Zippel wrote:
    > Hi,
    >
    > On Sat, 2 Dec 2006, Al Viro wrote:
    >
    > > > You need some more magic macros to access/modify the data field.
    > >
    > > Which is done bloody rarely. grep and you'll see... BTW, there are
    > > other reasons why passing struct timer_list * is wrong:
    > > * direct calls of the timer callback
    >
    > Why should that be wrong?

    Need to arrange a struct timer_list?

    > > * callback being the same for two timers embedded into
    > > different structs
    >
    > That's done bloody rarely as well.
    >
    > > * see a timer callback, decide it looks better as a tasklet.
    > > What, need a different glue now?
    >
    > What's wrong with changing the prototype? If you don't do it, the compiler
    > will complain about it anyway.

    How about "not having to change it at all"?

    > > Look, it's a delayed call. The less glue we need, the better - the
    > > rules are much simpler that way, so that alone means that we'll get
    > > fewer fsckups.
    >
    > You have the glue in a different place, so what?

    Where?

    > The other alternative has real _practical_ value in almost every case,
    > which I very much prefer. What's wrong with that?

    Lack of any type safety whatsoever, magic boilerplates in callback instances,
    rules more complex than "your callback should take a pointer, don't cast
    anything, it's just a way to arrange for a delayed call, nothing magical
    needed"?
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-12-02 23:43    [W:3.466 / U:0.256 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site