Hi Henrik,
At 02.51 28/10/2006, Henrik Nordstrom wrote:
tis 2006-10-24 klockan 08:24 +0200 skrev Guido Serassio:
> Sure, but some oddity comes directly from Microsoft "features" .... :-)
> Windows select() is only similar to the Unix one ....
Sorted out the differences and whipped up a new comm_select_win32.c file
(untested). Please check if it works. It approaches the HANDLE -> fd
lookup more in line with normal FD_ISSET which should be slightly faster
as less data to loop over.
Great !!! :-)
Basically it seems to work.
But it give to me a strange feeling when loading some complex page
with many embedded objects, like images, style sheets or .js objects:
The browser doesn't complete the page load for many seconds, but at
the end the object is retrieved.
Looking to cachemgr file descriptors, it seems that the object is
immediately loaded from the original server, but Squid returns the
object to the client only after the connection timeout.
Some sample sites:
msdn.microsoft.com
support.microsoft.com
www.osnews.com
Also whipped up a comm_poll_win32.c file which in theory should work on
Vista/Longhorn and perform significantly better thanks to it's static
mappings allowing efficient HANDLE -> fd lookups.
Interesting thing.
I was still not informed of the new WSAPoll() in Windows Vista API.
Would be good if you could test the new comm_select_win32.c. And if
interested play with comm_poll_win32.c (but due to the OS dependencies
it's a bit early to deploy such builds I suppose..)
May also be interesting to look into using WSAAsyncSelect(), the win32
equivalence to kqueue/epoll with some edge/level twists. It's interface
looks like a quite good fit for our event loop, and allows for a trivial
HANDLE->fd mapping (just use the fd number as event message). But then
got a little lost as I am not familiar with how to handle Windows event
loops in non-windowed appliecations.. i.e. what window handle should be
given to WSAAsyncSelect? And where is the resulting window messages
received?
Henrik, but you are becoming a Windows programmer ? ... :-))))))
About your question, it's not so clear.
Teorically any non GUI Windows application should create a hidden
Window to use WSAAsyncSelect().
But looking in this KB article :
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q181611
"WSAAsyncSelect maps socket notifications to Windows messages and is
the best model for a single threaded GUI application.
WSAEventSelect uses WSAEnumNetworkEvents to determine the nature of
the socket notification on the signaling event and maps socket
notifications by signaling an event. This is a useful model for
non-GUI applications that lack a message pump, such as a Windows NT
service application."
And there is another big question about WSAEventSelect() and friends:
http://www.tangentsoft.net/wskfaq/advanced.html#64sockets
It could handle only 64 sockets at a time.
Looking to comments and opinion with google, it seem's that I/O
Completion ports is the better solution on Windows
Regards
Guido
-
========================================================
Guido Serassio
Acme Consulting S.r.l. - Microsoft Certified Partner
Via Lucia Savarino, 1 10098 - Rivoli (TO) - ITALY
Tel. : +39.011.9530135 Fax. : +39.011.9781115
Email: [EMAIL PROTECTED]
WWW: http://www.acmeconsulting.it/
