On 03.09.25 12:44, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
The series brings two things:
1. unify code which sets fds blocking/non-blocking through the whole
source
2. for fds, which comes from qio_channel_readv_full(), stop making
them blocking in generic code, and move this logic to the callers,
all except coming from migration qemu-file (see last patch)
Oops, I found commit
commit ff5927baa7ffb9c97873a071f6a8d85a3584182b
util: rename qemu_*block() socket functions
The qemu_*block() functions are meant to be be used with sockets (the
win32 implementation expects SOCKET)
Over time, those functions where used with Win32 SOCKET or
file-descriptors interchangeably. But for portability, they must only be
used with socket-like file-descriptors. FDs can use
g_unix_set_fd_nonblocking() instead.
Rename the functions with "socket" in the name to prevent bad usages.
This is effectively reverting commit f9e8cacc5557e43 ("oslib-posix:
rename socket_set_nonblock() to qemu_set_nonblock()").
, which I effectively revert with these series..
Marc-André, Stefan could you take a look at my series?
I'm sure, that it's good to have one good interface, with errp and error
checking, instead of bucket of different functions, and making Error by
hand in many cases.
Except for the logic with files vs sockets, mentioned in the old commit.
Still, does it really make sense? It seems good to have a wrapper for
g_unix_set_fd_nonblocking() callded on FDs too..
So, formally, on top of my series I may add
bool qemu_socket_set_blocking(int fd, bool block, Error **errp)
{
return qemu_set_blocking(fd, block errp);
}
and use it where _socket_ functions were used.
But that will not prevent someone in future to use qemu_set_blocking(), where
qemu_socket_set_blocking() should be used. No sense in it..
I think, in Windows, if we try to make non-socket to be non-blocking, we should
get
a meaningful error, do we?
--
Best regards,
Vladimir
