Re: arca-1-against-pre-2.1.127-3
Gerard Roudier (groudier@club-internet.fr)
Tue, 3 Nov 1998 21:25:09 +0100 (MET)
> On Mon, 2 Nov 1998, Andrea Arcangeli wrote:
>
> > On Mon, 2 Nov 1998, Gerard Roudier wrote:
> >
> > >Even if not stated so, I think the 'next' field shall be considered as
> > >part of timer implementation not available to applications. We may call
> >
> > Also using timer->expires directly would not be a good high level c++
> > implementation. Gerard, do a c++ port of the linux kernel and I' ll agree
> > with you. Right now my patch fix a _real_ C bug in C. I can agree that it
> > would be better to use a bit more high level function (as I' ll do now and
> > thanks for the suggestion) but I am very more worried to fix a real bug in
> > a obvious simple and __safe__ way.
>
> Andrea,
>
> Given all the ugly C++ code I have had to suffer of, I will stick with
> simple C for the moment.
>
> Your timer_pending() primitive is much better. However, I am not sure such
> a primitive is useful enough for the timer handling to be complexify in a
> way that will allow to implement it safely.. My approach is likely to
> design things so that I will not need such a primitive.
>
> Never require a feature that you donnot really need.
>
> BTW, I know that your patch doesn't address any code of yours. So you may
> not consider my remark against your proposal.
Andrea,
Just overloading my answer:
Just based on semantic considerations, timer_add()/timer_delete() makes
sense but timer_pending() makes races. In fact timer_pending() may just
lie to users that donnot implement appropriate ressource synchronization
using spinlocks or whatever would do the correct things. There are O/Ses
that just allocate timer storage in some opaque pool. Some others even
donnot provide any handle for the timer. Note that the latter donnot allow
to provide the bogus timer_pending() primitive. I would suggest the author
of the code to fix the design of his code first. Note, that it may happen
that this code actually works, but I think that it has design problems
anyway.
Regards,
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/