> > > - If I'm correct that pipes have a 4K kernel buffer, then writing 1
> > > byte shouldn't cause this situation, as the buffer is well more than
> > > half empty. Is this still a bug?
> >
> > The pipe code uses totally full/empty. Im not sure why that was chosen
>
> Just a quick guess: m
On Fri, 3 Nov 2000, Paul Marquis wrote:
> It shows that even though select() says a file descriptor is not
> writable, a write() can still succeed. This code is not used anywhere
> in the real world, or at least my real world :-P. It just demonstrates
> "the bug".
>
It demonstrates nothing ex
On Thu, Nov 02, 2000 at 11:55:52PM +, Alan Cox <[EMAIL PROTECTED]> wrote:
> > - If I'm correct that pipes have a 4K kernel buffer, then writing 1
> > byte shouldn't cause this situation, as the buffer is well more than
> > half empty. Is this still a bug?
>
> The pipe code uses totally full/
> > Semantic issues aside, since Apache does the test I mentionned earlier
> > to determine child status and since it could be misled, should this
> > feature be turned off?
>
> Or made smarter yes
i'm scratching my head wondering what i was thinking when i wrote that
code. the specific thing t
It shows that even though select() says a file descriptor is not
writable, a write() can still succeed. This code is not used anywhere
in the real world, or at least my real world :-P. It just demonstrates
"the bug".
Richard B. Johnson" wrote:
> Not as I see it. This is clearly a code bug. Look
On Thu, 2 Nov 2000, Paul Marquis wrote:
> In the code sample, there is a loop that is run four times. During
> each iteration, a call to select() and write() is done, while every
> other iteration does a read(). Between the 1st and 2nd calls to
> write(), as well as the 3rd and 4th, select() fa
> Has anyone considered the possibility of expanding the buffer of
> high-traffic pipes?
Do that too much and the data falls out of L1 cache before we context switch.
Its a rather complex juggling game. DaveM's kiovec pipe patches avoid some of
this by cheating and going user->user
-
To unsubsc
Followup to: <[EMAIL PROTECTED]>
By author:Paul Marquis <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Okay, I see your point, thanks. A couple of comments/questions:
>
> - Does this make sense with devices with small kernel buffers? From
> my experimentation, pipes on Linux have a
> - Does this make sense with devices with small kernel buffers? From
> my experimentation, pipes on Linux have a 4K buffer and tend to be
> read and written very quickly.
It makes sense for all things I suspect
> - If I'm correct that pipes have a 4K kernel buffer, then writing 1
> byte shoul
Okay, I see your point, thanks. A couple of comments/questions:
- Does this make sense with devices with small kernel buffers? From
my experimentation, pipes on Linux have a 4K buffer and tend to be
read and written very quickly.
- If I'm correct that pipes have a 4K kernel buffer, then writin
> I'm not exactly sure what you mean by this statement. Would you mind
> explaining further?
Well take a socket with 64K of buffering. You don't want to wake processes
waiting in select or in write every time you can scribble another 1460 bytes
to the buffer. Instead you wait until there is 32K
I'm not exactly sure what you mean by this statement. Would you mind
explaining further?
Alan Cox wrote:
> Most fast devices wake up when buffers are half empty for example.
--
Paul Marquis
[EMAIL PROTECTED]
If it's tourist season, why can't we shoot them?
-
To unsubscribe from this list: sen
In the code sample, there is a loop that is run four times. During
each iteration, a call to select() and write() is done, while every
other iteration does a read(). Between the 1st and 2nd calls to
write(), as well as the 3rd and 4th, select() fails, but all write()'s
and read()'s succeed. The
> I guess in theory, you're right, though if a write() could succeed,
> shouldn't select() say that it would?
Thats certainly not normal for a lot of devices. Most fast devices wake up
when buffers are half empty for example.
Alan
-
To unsubscribe from this list: send the line "unsubscribe lin
I guess in theory, you're right, though if a write() could succeed,
shouldn't select() say that it would?
And this assumes you're calling select() with a timeout. In Apache,
the caretaker process wakes up periodically and polls the pipe with a
timeout of zero. If it gets back the pipe is not wr
On Thu, 2 Nov 2000, Alan Cox wrote:
> > that are log file handlers are dead. If select() reports it can't
> > write immediately, Apache terminates and restarts the child process,
> > creating unnecessary load on the system.
>
> Is there anything saying that select has to report ready the instan
> that are log file handlers are dead. If select() reports it can't
> write immediately, Apache terminates and restarts the child process,
> creating unnecessary load on the system.
Is there anything saying that select has to report ready the instant a byte
would fit. Certainly its better for pe
17 matches
Mail list logo
