I known about this blog post:
https://daniel.haxx.se/blog/2012/10/10/wsapoll-is-broken/
But it looks like things in Winsock has improved in 10 years.
Experimenting with using WSAPoll()' in select.c, it works fine
except for the 'POLLPRI' bit (throwing 'WSAEINVAL').
MSDN [1] states:
Priority data may be read without blocking. This flag is
not supported by the Microsoft Winsock provider.
So with this patch:
--- a/lib/select.c 2022-07-05 11:24:59
+++ b/lib/select.c 2022-07-05 12:39:24
@@ -309,7 +309,16 @@
pending_ms = -1;
else
pending_ms = 0;
+
+#ifdef USE_WINSOCK
+ /* Remove the unsupported 'POLLPRI' bits */
+ for (i = 0; i < nfds; i++)
+ ufds[i].events &= ~POLLPRI;
+ r = WSAPoll(ufds, nfds, pending_ms);
+#else
r = poll(ufds, nfds, pending_ms);
+#endif
+
if(r <= 0) {
if((r == -1) && (SOCKERRNO == EINTR))
/* make EINTR from select or poll not a "lethal" error */
-----
it works fine. But I've done little testing. And I've not seen
any improvement in speed or CPU-load.
So how about supporting 'WSAPoll()' with a 'HAVE_POLL_FINE'?
Perhaps this could be configurable? Like in
nmap --nsock-engine=poll, nmap --nsock-engine=iocp etc?
[1]
https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-wsapoll#remarks
--
--gv
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
