--- "Justin T. Gibbs" <[EMAIL PROTECTED]> wrote:
> >I believe I had this conversation with Justin Gibbs earlier; he told
> >me that the callout consumers (network, cam) had to be aware of the
> >race and handle this if it matters. I don't particularly like complicating
> >the callout handlers
>I believe I had this conversation with Justin Gibbs earlier; he told
>me that the callout consumers (network, cam) had to be aware of the
>race and handle this if it matters. I don't particularly like complicating
>the callout handlers as illustrated above, though, so if a better scheme
>is po
On Wed, 10 Jul 2002, Archie Cobbs wrote:
> John Baldwin writes:
> > It is the same problem. What we do is change callout_stop() to let you know if
> > it actually stopped the timeout or not. You then have to use your own locking
> > and synchronization in the timeout function and yourself to c
[ NOTE: I'm moving this discussion to [EMAIL PROTECTED] ]
John Baldwin writes:
> > What do you think of the idea of letting the timer code (optionally)
> > handle all the locking and race conditions?
>
> I'm not sure it can in a clean fashion since of the few cases I've known
> so far each clie
On 10-Jul-2002 Archie Cobbs wrote:
> John Baldwin writes:
>> It is the same problem. What we do is change callout_stop() to let you know if
>> it actually stopped the timeout or not. You then have to use your own locking
>> and synchronization in the timeout function and yourself to close the re
John Baldwin writes:
> It is the same problem. What we do is change callout_stop() to let you know if
> it actually stopped the timeout or not. You then have to use your own locking
> and synchronization in the timeout function and yourself to close the rest of
> the race.
OK, thanks.
What do y
On 10-Jul-2002 Archie Cobbs wrote:
> John Baldwin writes:
>> > code would be modified to fit this new behaviour, besides this, everywhere
>> > callout_stop() is used need to hold sched_lock and do a mi_switch() and
>> > modify td_flags is also unacceptable, this SMP race should be resolved in
John Baldwin writes:
> > code would be modified to fit this new behaviour, besides this, everywhere
> > callout_stop() is used need to hold sched_lock and do a mi_switch() and
> > modify td_flags is also unacceptable, this SMP race should be resolved in
> > kern_timeout.c.
>
> How would you re
I'll work out a patch to see if my idea works.
David Xu
--- John Baldwin <[EMAIL PROTECTED]> wrote:
>
> On 08-Jul-2002 David Xu wrote:
> > I want to set an flag bit CALLOUT_PROCESSING in callout.c_flags,
> > before softclock() releases callout_lock and start requesting
> > callout.c_func(), so
On 08-Jul-2002 David Xu wrote:
> I want to set an flag bit CALLOUT_PROCESSING in callout.c_flags,
> before softclock() releases callout_lock and start requesting
> callout.c_func(), so callout_stop can find that callout is processing
> by softclock and wait, after softclock processed the callout,
TECTED]>; "Julian Elischer" <[EMAIL PROTECTED]>
Sent: Tuesday, July 09, 2002 3:27 AM
Subject: RE: Timeout and SMP race
>
> On 04-Jul-2002 David Xu wrote:
> > while we are getting rid of Giant, current race condition between
softclock()
> > and callout_stop() is u
On 04-Jul-2002 David Xu wrote:
> in RELENG_4, when one calls callout_stop() (not nested in softclock execute
> path
> , I am not talking about this case), after it returns, he can believe that the
> callout is truely stopped, however in CURRENT, this assumption is false, now we
>
> must care if
On 04-Jul-2002 David Xu wrote:
> while we are getting rid of Giant, current race condition between softclock()
> and callout_stop() is unacceptable. the race causes two many places in source
> code would be modified to fit this new behaviour, besides this, everywhere
> callout_stop() is used n
On Fri, Jul 05, 2002 at 02:38:08AM +1000, Bruce Evans wrote:
> On Thu, 4 Jul 2002, Jonathan Lemon wrote:
>
> > In article
>[EMAIL PROTECTED]> you
>write:
> > >in RELENG_4, when one calls callout_stop() (not nested in softclock execute
> > >path
> > >, I am not talking about this case), after it
On Thu, 4 Jul 2002, Jonathan Lemon wrote:
> In article
>[EMAIL PROTECTED]> you
>write:
> >in RELENG_4, when one calls callout_stop() (not nested in softclock execute
> >path
> >, I am not talking about this case), after it returns, he can believe that the
> >callout is truely stopped, however i
e
timer callback is completely gone immediately after calling callout_stop().
--
Jonathan
>- Original Message -
>From: "Bruce Evans" <[EMAIL PROTECTED]>
>To: "David Xu" <[EMAIL PROTECTED]>
>Cc: "Julian Elischer" <[EMAIL PROTECTED]>
home, I must send
it from yahoo. :(
-David Xu
- Original Message -
From: "Bruce Evans" <[EMAIL PROTECTED]>
To: "David Xu" <[EMAIL PROTECTED]>
Cc: "Julian Elischer" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, July 04, 2
On Thu, 4 Jul 2002, David Xu wrote:
> - Original Message -
> From: "Julian Elischer" <[EMAIL PROTECTED]>
> To: "David Xu" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Thursday, July 04, 2002 4:36 PM
> Subject: Re: Timeout
- Original Message -
From: "Julian Elischer" <[EMAIL PROTECTED]>
To: "David Xu" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, July 04, 2002 4:36 PM
Subject: Re: Timeout and SMP race
>
>
> On Thu, 4 Jul 2002, David Xu
On Thu, 4 Jul 2002, David Xu wrote:
> while we are getting rid of Giant, current race condition between softclock()
> and callout_stop() is unacceptable. the race causes two many places in source
> code would be modified to fit this new behaviour, besides this, everywhere
> callout_stop() is
20 matches
Mail list logo
