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 Wed, 20 Apr 2005 11:32:29 GMT
Bill Stoddard wrote:
> William A. Rowe, Jr. wrote:
> 
>> This makes alot of sense.  But we are talking about the need for
>> large scale parallelism, not discrete events.  Once a given unit
>> of I/O work can be performed on a given socket or pipe, it's going
>> to be time to farm it out to a worker.
> 
> If I understand your meaning, that's one of the nice features of IOCPs. 
> You can block your worker threads against an IOCP (actual call is 
> GetQueuedCompletionStatus()) and the NT kernel will dispatch threads in 
> LIFO order to handle io completion notifications.  Of course we would 
> hide all those details in an apr_pollset_* call.
>

What we need is scalable solution that will break 64 handles limit.
Nothing less, nothing more. Anything else would IMO have to go to a
different API, not apr_pollset_*, but rather something like threadpool
or worker queue. My original patch was intended to break (and it does)
the 64 handles barrier for socket events, so that the same API can be
used cross platform. Although creating up to 64 threads
(as OtherBill proposed) would give an option to poll on pipes, the
present proposal, even using Sleep is much faster then the current
one used (using select). I even think that 1 ms Sleep will not burn
the CPU at all, an that is BTW the resolution of any WaitFor* function.

Further more, setting FD_SETSIZE to a larger number prior including
<winsock2.h> allows the current implementation to break the 64
handles limit, and should be enough in most cases.
Anyhow, I propose that we set that value to 1024, to be consistent
with posix definitions for FD_SETSIZE.

Regards,
Mladen.



Mime
View raw message