[EMAIL PROTECTED] said:
> I think the proper fix, long term, is to fix our internal I/O routine
> APIs so that they are capable of returning a byte count _and_ an
> error. One day, that might be a useful thing to export to userspace.
The MTD code already does this.
--
dwmw2
-
To unsubscrib
On Mon, 19 Feb 2001 [EMAIL PROTECTED] wrote:
> Wakeup does not happen until _enough_ (1/3 of snbuf) of space in sndbuf
> is released, otherwise you will overschedule. So, as soon as
> write() goes to sleep, it will sleep waiting until 1/3 is released.
Of course. Thank you.
> If it is interrupt
Hello!
> You are right - our sendfile() implementation is broken. I have fixed it
Thank you!
> Investigation shows that the Linux network layer is behaving oddly. It
> seems that we are writing 4096 bytes to a socket. This proceeds in 4096
> byte chunks until the send buffer on the socket is f
On Mon, 19 Feb 2001, Chris Evans wrote:
> > BTW, if you have enough fast network, you probably can observe
> > that sendfile() is even not interrupted by signals. 8) But this
> > is possible to fix at least. BTW the same fix will repair SO_*TIMEO
> > partially, i.e. it will timeout after n*timeo
On Sun, 18 Feb 2001 [EMAIL PROTECTED] wrote:
> Hello!
>
> > Unfortunately, I discovered a bug with SO_SNDTIMEO/sendfile():
>
> None of the options apply to sendfile(). It is not socket level
> operation. You have to use alarm for it.
>
> BTW, if you have enough fast network, you probably can obs
Hello!
> .. unless that page was partially written, in which case a short write
> count is returned (rather than a timeout error), and the loop goes around
> again.
sendfile() does not return on partial write and tries to push more
until error. On fast link it most likely succeeds, so that it is
On Sun, 18 Feb 2001 [EMAIL PROTECTED] wrote:
> Hello!
>
> > So the actual timeout would be 2 * SO_SNDTIMEO.
>
> It will timeout if write of some page blocks for SO_SNDTIMEO.
.. unless that page was partially written, in which case a short write
count is returned (rather than a timeout error), a
Hello!
> So the actual timeout would be 2 * SO_SNDTIMEO.
It will timeout if write of some page blocks for SO_SNDTIMEO.
If transmission of any page never takes more than SO_SNDTIMEO it never
times out.
You can think about sendfile() as subroutine doing:
for (;;) {
read(4
On Sun, 18 Feb 2001 [EMAIL PROTECTED] wrote:
> Hello!
>
> > Unfortunately, I discovered a bug with SO_SNDTIMEO/sendfile():
>
> None of the options apply to sendfile(). It is not socket level
> operation. You have to use alarm for it.
Hi Alexey,
Actually sendfile() _does_ timeout using SO_SNDTI
Hello!
> Unfortunately, I discovered a bug with SO_SNDTIMEO/sendfile():
None of the options apply to sendfile(). It is not socket level
operation. You have to use alarm for it.
BTW, if you have enough fast network, you probably can observe
that sendfile() is even not interrupted by signals. 8)
Hi,
By the way - I tested SO_RCVLOWAT, another 2.4 addition. Good news this
time - seems to work fine.
Cheers
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-i
Hi Alexey,
This patch fixes my simple read()/write() tests, nice one. The behaviour
also now matches BSD (someone kindly donated me a FreeBSD shell for
testing).
Unfortunately, I discovered a bug with SO_SNDTIMEO/sendfile():
- Connect an AF_INET, SOCK_STREAM socket to a local listening socket.
Alexey,
Damn you are quick! :) Testing immediately
Cheers
Chris
On Sat, 17 Feb 2001 [EMAIL PROTECTED] wrote:
> Hello!
>
> > Unfortunately, it seems to be very buggy. Here are two buggy scenarios.
>
>
> --- ../vger3-010210/linux/net/ipv4/tcp.c Sat Feb 10 23:16:51 2001
> +++ linux/net/ipv4
Hello!
> Unfortunately, it seems to be very buggy. Here are two buggy scenarios.
--- ../vger3-010210/linux/net/ipv4/tcp.cSat Feb 10 23:16:51 2001
+++ linux/net/ipv4/tcp.cSat Feb 17 23:27:43 2001
@@ -691,6 +691,8 @@
set_current_state(TASK_INTERRUPTIBLE);
+
Hi,
I was glad to see Linux gain SO_SNDTIMEO in kernel 2.4. It is a very use
feature which can avoid complexity and pain in userspace programs.
Unfortunately, it seems to be very buggy. Here are two buggy scenarios.
1)
Create a socketpair(), PF_UNIX, SOCK_STREAM.
Set a 5 second SO_SNDTIMEO on
15 matches
Mail list logo
