Re: [Qemu-devel] [PATCH] socket: fix blocking udp recvfrom.

2019-02-28 Thread Samuel Thibault
llyzs, le ven. 01 mars 2019 12:27:31 +0800, a ecrit: > I believe this is because UDP packet can have 0 length payload. Ah, right, that one makes sense indeed. > I also found out that sometimes ioctlsocket() call can return error > (probably caused by my unstable wifi linux driver), in which case

Re: [Qemu-devel] [PATCH] socket: fix blocking udp recvfrom.

2019-02-28 Thread llyzs
Hi, I believe this is because UDP packet can have 0 length payload. I quote some resources here: https://stackoverflow.com/questions/12505892/under-linux-can-recv-ever-return-0-on-udp https://stackoverflow.com/questions/5307031/how-to-detect-receipt-of-a-0-length-udp-datagram I also found out

Re: [Qemu-devel] [PATCH] socket: fix blocking udp recvfrom.

2019-02-28 Thread Samuel Thibault
Hello, llyzs, le jeu. 28 févr. 2019 19:59:12 +0800, a ecrit: > Sometimes sorecvfrom() is called from slirp.c because revents == G_IO_IN, > however inside sorecvfrom() function, ioctlsocket() returns 0 bytes available > and recvfrom could be blocking indefinitely. This adds a non-blocking flag to

[Qemu-devel] [PATCH] socket: fix blocking udp recvfrom.

2019-02-28 Thread llyzs
Sometimes sorecvfrom() is called from slirp.c because revents == G_IO_IN, however inside sorecvfrom() function, ioctlsocket() returns 0 bytes available and recvfrom could be blocking indefinitely. This adds a non-blocking flag to recvfrom and checks data availability. --- slirp/socket.c | 4 +++-