Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (hermes.apache.org: local policy)
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <6.2.1.2.2.20050418115916.065e88e0@pop3.rowe-clan.net>
Date: Mon, 18 Apr 2005 12:08:12 -0500
To: Mladen Turk <mturk@apache.org>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: [WIN32] alternative apr_pollset implementation proposal
Cc: Paul Querna <chip@force-elite.com>,
        APR Developer List <dev@apr.apache.org>
In-Reply-To: <4263D8A2.5010204@apache.org>
References: <4263A807.8070808@apache.org>
 <4263D53F.9070800@force-elite.com>
 <4263D8A2.5010204@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:56 AM 4/18/2005, Mladen Turk wrote:
>Paul Querna wrote:
>
>>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.

Exactly the reason we have the existing limit.

>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 :).

Sleep() is not the answer.

I do have a productive suggestion though that we kicked around once or
twice.  Spin up helper threads (we can even keep a cache of them) to
handle each group of 64 events, and have them pop an event to the
parent thread once finished.  at 64x63 events, this could be quite
respectible.

Keep in mind, as you consider new designs for apr_poll, that the
longest standing issue is polling on files.  If you can solve both
issues in one whack, we would trip over each other getting your
patch committed :)