apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [WIN32] alternative apr_pollset implementation proposal
Date Mon, 18 Apr 2005 21:13:33 GMT
At 01:10 PM 4/18/2005, Mladen Turk wrote:
>William A. Rowe, Jr. wrote:
>>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.
>
>How did you think to catch the threads?
>Sharing them among multiple pollsets, or keeping them around per
>pollset?

Yes, we would have to signal on an event (perhaps, the thread
itself) to inform the master Waiter-upon-Wait's that a specific
tangle of wait events had popped.

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

>Well in that case it would be switch among WSA and Object events,
>not a big deal actually ;).

It's a rather huge deal - compare the API for waiting on File
objects with the unix poll() behavior :(

I had it working, at one point, and came up short in two or three
respects.  Somewhere on one of these boxes sits that patch :-/

Bill 


Mime
View raw message