The send operations are waiting on the peer's socket buffer, but we shall
use our timeout value. Provide a test for that.
Fixes: d15792780760ef94647af9b377b5f0a80e1826bc
Reported by: phk
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
Do we not block at all when sending on a dgram socket and the receiver has insufficient space?
Comment Actions
I have two comments in addition to the inline ones:
- The commit message says "repair". That implies that the sockopt used to work but no longer does. If that's true, can you please include in your commit message the hash of the commit that broke it?
- One-second sleeps in test suites can add up to a lot. You probably don't need to sleep for so long in order to test the sock opt. Can you reduce the sleep time? FWIW I use 0.1s sleeps in the fusefs test suite and I've heard no complaints there.
- What exactly was the old behavior that you are correcting? Did we wait forever, ignoring the sockopt?
| tests/sys/kern/unix_stream.c | ||
|---|---|---|
| 501 | Why use a macro here? It could just be a constant. | |
| 509 | If this is testing the errno returned by send, then it should come before the second clock_gettime call. | |
| 511 | I think that this assertion will be unreliable. The time difference could be anything greater than or equal to SECONDS. So you should check like this: | |
Comment Actions
This was found by Varnish Cache testcase s00012, which passes on 14.3p4 and fails on 15.0-ALPHA5 (Those are the best coordinates I have)
Failure mode is that the socket option is ignored and we never time out.
Comment Actions
Yes, datagram shall not block. It returns ENOBUFS when receiver has no space. This is a historical behavior and once I tried to change that ENOBUFS, and there was a lot of fallout on different application sides. Go runtime in the first place.