PERFORCE change 126330 for review

[Attilio Rao]

2007/9/13, Pawel Jakub Dawidek <pjd at freebsd.org>:
> On Thu, Sep 13, 2007 at 01:18:41AM +0200, Attilio Rao wrote:
> > 2007/9/13, Pawel Jakub Dawidek <pjd at freebsd.org>:
> > > On Wed, Sep 12, 2007 at 03:49:55PM -0700, Kip Macy wrote:
> > > > Andrew Thompson explicitly asked for the possibility of shared acquisition.
> > >
> > > A flag for callout_init_lock() will be enough? Or it wants it to be
> > > sometimes acquired shared and sometimes exclusive?
> >
> > If it was me I would avoid the 'static' requirement for these stuffs.
>
> Actually I don't see why one would want to call the same handler with
> different locked lock. I think a flag for callout_init_lock() should be
> enough, exactly in the same way we have CALLOUT_RETURNUNLOCKED - we
> don't decide if the handler returns with lock unlock at callout_reset()
> time, but at callout_init_mtx() time. The thing is that you know the
> handler and you know if it needs to modify shared data or not at init
> time. And for the very uncommon cases, you can always downgrade the lock
> from within the handler.
>
> All in all, I think a flag for callout_init_lock() is enough. Do you
> feel convinced?

Yes, probabilly having an initialization flag is good enough.
I was just thinking if one can find cases where different ways for
handler locking can happen, so that having a general way to avoid this
would be better.
But, as you explain, an intialization flag is a good solution as well
(and avoids any external API modify).

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein