[PATCH] tst-cancel4: Make blocking on write more portable
We should not be assuming how PF_UNIX buffering works and just choose a
"proper" write size. The additional pthread_testcancel() call after
write() shows it: we don't really control how buffering works.
We can however easily use select to fill the buffer byte by byte until
select() says that write() will block, in which case write() will not
even be able to perform a partial write.
We should however do this on the same side of the socketpair as the
read() tests, otherwise read() would get data from this. This is
actually fine: we can just read() and write() on the same side, with
nobody consuming or producing data on the other side.
* nptl/tst-cancel4-common.h (set_socket_buffer): Write data on the
socket until select informs us that it would block.
* nptl/tst-cancel4-common.c (do_test): Set send buffer size on fds
instead of fds.
* nptl/tst-cancel4.c (tf_write, tf_writev): Use fds instead of
(tf_write): Do not call pthread_testcancel() after write(), we are now not
even supposed to get partial writes.
(tf_send, tf_sendto): Fill socket buffer after connecting.
nptl/tst-cancel4-common.c | 2 +-
nptl/tst-cancel4-common.h | 19 ++++++++++++++++++-
nptl/tst-cancel4.c | 16 ++++++----------
3 files changed, 25 insertions(+), 12 deletions(-)
if (arg == NULL)
- fd = fds;
+ fd = fds;
char fname = "/tmp/tst-cancel4-fd-XXXXXX";
@@ -167,10 +167,6 @@ tf_write (void *arg)
memset (buf, '\0', sizeof (buf));
s = write (fd, buf, sizeof (buf));
- /* The write can return a value higher than 0 (meaning partial write)
- due to the SIGCANCEL, but the thread may still be pending
- cancellation. */
- pthread_testcancel ();
So it only fills 2 bytes on the socket buffer, but later the write *does*
return with side-effects indicating that it has at least written 2240 bytes.
I haven't investigate further on Linux kernel the iteration between
SOL_SOCKET, buffer filling and blocking operations. But it does show that
is indeed system specific and partial write might still occur even with
clever tricks. I am also not sure if this is something specific to
socketpair and if using a named socket might have different results.
Are you trying to make the tests behave better on Hurd? If so, in how
exactly Hurd behaves different than Linux in this case?