[EMAIL PROTECTED] wrote: >On 17 Jul 2002 [EMAIL PROTECTED] wrote: > > > >>trawick 2002/07/17 15:15:01 >> >> Modified: . STATUS >> Log: >> somebody please tell me I don't know how to read C code anymore >> >> (I guess the pool for an Apache socket will grow on every read/write >> operation that would block.) >> >> + * apr_poll() grows the pool (e.g., pchild or the thread's pool) on >> + each call... Apache MPMs don't have logic to work around this >> + issue. >> >> > >Well the goal was to optimize out that palloc over time, which just >requires some profiling to find the most likely cases. Also, on platforms >with alloca, we can allocate the pollset on the stack. All of this has >been spelled out on the list, but I haven't had the time to do it yet. >
What's the plan for handling apr_poll() calls with really large numbers of descriptors? It's trivial to optimize for small numbers of descriptors by putting a pollset on the stack, but that won't work if someone tries to use apr_poll with, say, a thousand descriptors. And an app that passes that many descriptors to poll is likely running an event loop in which it will keep calling poll over and over, so we won't be able to use apr_palloc() there. --Brian
