On 2000-Aug-07 14:49:34 -0700, David Greenman <[EMAIL PROTECTED]> wrote:
> No, that's not true, and there are many examples in the kernel where a
>bogus wakeup would lead to bad things happening. I recall some code in the
>advisory locking code, and VM system, that assume that there is only one
In message <[EMAIL PROTECTED]>, Stephen McKay writes:
>Regardless of the history of it all, FreeBSD is full of places where
>unexpected wakeups can stuff you right up. Should we regard tsleep() like
>the older sleep() call, as suspect, and program defensively? Should we
>be pragmatic, admit "We
Well, I've failed in my main objective (to deuglify the shutdown messages),
but an interesting debate has resulted instead, so I can't feel too bad.
I did a little research to support my position on sleep/wakeup, and here's
the best I have. This is pretty long, and unlikely to shake your world v
> It's not just that, if you always have to cover your behind when
> doing tsleep you may wind up masking wakeup bugs. Places like
> "vfs_bio.c" line 586 of 3182:
>
> bp->b_xflags |= BX_BKGRDWAIT;
> tsleep(&bp->b_xflags, PRIBIO, "biord", 0);
> if (bp->b_
* David Greenman <[EMAIL PROTECTED]> [000807 23:15] wrote:
> >In article <[EMAIL PROTECTED]>, David Greenman
> ><[EMAIL PROTECTED]> wrote:
>
> >Obviously the waker-upper knows that the condition is true. Otherwise
> >the existing code which doesn't check wouldn't work. In the expensive
> >cases
>In article <[EMAIL PROTECTED]>, David Greenman
><[EMAIL PROTECTED]> wrote:
>> >I will add that this is the pattern that Kirk teaches in his kernel
>> >internals class.
>>
>>If that's true,
>
>Do you want me to fax you a copy of page 15 of his class notes from
>the course he gave at last year'
In article <[EMAIL PROTECTED]>, David Greenman
<[EMAIL PROTECTED]> wrote:
> >I will add that this is the pattern that Kirk teaches in his kernel
> >internals class.
>
>If that's true,
Do you want me to fax you a copy of page 15 of his class notes from
the course he gave at last year's FreeBSD
>I will add that this is the pattern that Kirk teaches in his kernel
>internals class.
If that's true, then he should practice what he preaches. Some of the code
that I'm refering to (e.g. lockf) was apparantly written by him.
I'll say again, however, that some of the cases that rely on the
In article <[EMAIL PROTECTED]>,
Alfred Perlstein <[EMAIL PROTECTED]> wrote:
> * Poul-Henning Kamp <[EMAIL PROTECTED]> [000807 10:03] wrote:
> >
> > Then this code should be changed to do the right thing, which is
> > to *always* check the condition being slept on before proceeding.
>
> Can you
>I did say "as a general rule". If you know that "by design" nothing else
>is going to mess with what you're sleeping on before you wake up then
>you can make tighter optimisations but that's not the general case.
>There is such a thing as over optimisation though and for the sake of a
>simple if
David Greenman wrote:
>
> >In the particular case of sleeping though, a woken process does need to
> >check the condition that it slept on because one of the other processes
> >sleeping on that resource may have had a chance to run first and changed
> >some state. So as a general rule, you should
>In the particular case of sleeping though, a woken process does need to
>check the condition that it slept on because one of the other processes
>sleeping on that resource may have had a chance to run first and changed
>some state. So as a general rule, you shouldn't assume that everything
>is fi
David Greenman wrote:
>
> >>Can you give a reason why we'll have to now start coding defensively
> >>because our arguments to tsleep() are just "advisory" now?
> >
> >It is not something we "suddenly have to do" it's been The Right Way
> >even since I first sharpened my teeth on unix kernels many
Just a quick perusal of the kernel code shows a number of possible
unexpected side effects from unexpected wakeups. I see several places
where a 'WANTED' flag is set in a loop waiting for something and assumed
to be cleared after the tsleep() returns. Some of these side effects
>>Can you give a reason why we'll have to now start coding defensively
>>because our arguments to tsleep() are just "advisory" now?
>
>It is not something we "suddenly have to do" it's been The Right Way
>even since I first sharpened my teeth on unix kernels many years ago.
Uh, Poul, I think y
In message <[EMAIL PROTECTED]>, Alfred Perlstein writes:
>> Then this code should be changed to do the right thing, which is
>> to *always* check the condition being slept on before proceeding.
>
>Can you give a reason why we'll have to now start coding defensively
>because our arguments to tslee
* Poul-Henning Kamp <[EMAIL PROTECTED]> [000807 10:03] wrote:
> In message <[EMAIL PROTECTED]>, Matt Dillon writes:
> >:> * Stephen McKay <[EMAIL PROTECTED]> [000805 08:49] wrote:
> >:> >
> >:> > Patch 2 is smaller and possibly controversial. Normally bufdaemon and
> >:> > syncer are sleeping wh
In message <[EMAIL PROTECTED]>, Matt Dillon writes:
>:> * Stephen McKay <[EMAIL PROTECTED]> [000805 08:49] wrote:
>:> >
>:> > Patch 2 is smaller and possibly controversial. Normally bufdaemon and
>:> > syncer are sleeping when they are told to suspend. This delays shutdown
>:> > by a few boring
:> * Stephen McKay <[EMAIL PROTECTED]> [000805 08:49] wrote:
:> >
:> > Patch 2 is smaller and possibly controversial. Normally bufdaemon and
:> > syncer are sleeping when they are told to suspend. This delays shutdown
:> > by a few boring seconds. With this patch, it is zippier. I expect peop
In message <[EMAIL PROTECTED]> Stephen McKay writes:
: And back to the simpler bit (the bike shed bit). Does everyone else actually
: *like* the verbose messages currently used? And the gratuitous extra newline
: in the "syncing..." message?
I like the newer messages in your patch, but I don't
> * Mike Smith <[EMAIL PROTECTED]> [000807 01:25] wrote:
> > > * Stephen McKay <[EMAIL PROTECTED]> [000805 08:49] wrote:
> > > >
> > > > ... every sleeping process should expect
> > > > to be woken for no reason at all. Basic kernel premise.
> > >
> > > You better bet it's controversial, this i
* Mike Smith <[EMAIL PROTECTED]> [000807 01:25] wrote:
> > * Stephen McKay <[EMAIL PROTECTED]> [000805 08:49] wrote:
> > >
> > > Patch 2 is smaller and possibly controversial. Normally bufdaemon and
> > > syncer are sleeping when they are told to suspend. This delays shutdown
> > > by a few bor
> * Stephen McKay <[EMAIL PROTECTED]> [000805 08:49] wrote:
> >
> > Patch 2 is smaller and possibly controversial. Normally bufdaemon and
> > syncer are sleeping when they are told to suspend. This delays shutdown
> > by a few boring seconds. With this patch, it is zippier. I expect people
>
* Stephen McKay <[EMAIL PROTECTED]> [000805 08:49] wrote:
>
> Patch 2 is smaller and possibly controversial. Normally bufdaemon and
> syncer are sleeping when they are told to suspend. This delays shutdown
> by a few boring seconds. With this patch, it is zippier. I expect people
> to complai
On Sun, 06 Aug 2000 01:49:49 +1000, Stephen McKay wrote:
> I think shutdown time has gotten uglier and slower than it needs to be.
Probably because you already understand what's going on. The existing
text for the "stopping process" messages is designed to help folks stay
calm while their mac
I'm off in a few days for a couple months of tourism in Europe (no, no need
for sympathy!), so I'm dumping these couple ideas on you and running.
I think shutdown time has gotten uglier and slower than it needs to be.
I want to apply these patches (well, at least the first one) before I escape
ra
26 matches
Mail list logo
