apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject Re: [WIN32] alternative apr_pollset implementation proposal
Date Mon, 18 Apr 2005 15:56:18 GMT
Paul Querna wrote:
> Why can't this be an apr_thread_mutex?

It's the same thing.

> Hmm. I am not really happy with this loop.  I don't think this will be
> very fast with thousands of Sockets.  I am far from an expert on Win32,
> but why can't 'WSAWaitForMultipleEvents' be used, instead of iterating
> every socket?

It has a 64 handles limit, so you will need to have multiple threads,
that could lead to hundreds of them,
or like in mpm_winnt wait_for_many_object call and have multiple
WaitForMultipleEvents calls and check after the timeout.

Unlike WaitForMultipleObjects, for sockets we have WSAEnumNetworkEvents
that will check the state of the socket, so there is no need to call
something that will timeout in a loop with a Sleep already being there.

Compared with classical select call on 1K sockets, found that the
implementation is faster, probably because I used smaller Sleep :).

> Ack.  If your sockets are idle, this will just spin the CPU -- I wish
> this could be pushed down to a single system call, ala
> WSAWaitForMultipleEvents, instead of us having to fake the timeout.

Yes, it will spin the CPU, but there is a Sleep call that keeps that
to a very low value.


View raw message