apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Mansion" <ja...@wgold.demon.co.uk>
Subject RE: [WIN32] alternative apr_pollset implementation proposal
Date Tue, 19 Apr 2005 05:04:18 GMT
>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.

This is a very bad idea, it would be better to use overlapped IO
and focus on when requests complete and work on that model,
and deprecate poll or fake it with a buffer to handle the
mismatch between 'done' and 'try now'.

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

Isn't poll on files more a theoretical benefit than actual,
since they always signal as ready?

James




Mime
View raw message