[RFC] supplicant: Support poll() in eloop.

[Ben Greear]

On 02/12/2012 11:20 AM, Jouni Malinen wrote:
> On Sun, Feb 12, 2012 at 09:14:21AM -0800, Ben Greear wrote:
>> Err, that RFC code had an off-by one bug in it around the code that
>> determined when to increase the poll-fd array..did you find
>> that, or maybe work around it some other way?
>
> Cannot really say that I did and it didn't even hit my initial test with
> large number of sockets. Anyway, I fixed it now before the commit had
> even been pushed to the main repository.
>
> The other part that's a bit problematic is the handling of allocation
> failures in eloop_sock_table_add_sock(). In practice, that would result
> in assert() or NULL pointer deference depending on which allocation
> failed.

Yeah.  I think if memory alloc fails we are just out of luck
in this code.  We could exit the entire process cleanly, but
I don't know of any good way to work-around the failure and keep
running smoothly.  I doubt it would happen in practice, however.

> While going through some tests, it started to look like this could be
> optimized quite a bit by not using the separate map array at all and
> just updating pollfds array when sockets are added or removed instead of
> doing separately for each poll() call. I wouldn't expect this to make
> much of a difference for small number of sockets, but maybe it starts
> showing up with huge number.

I plan to do some optimization work on supplicant sometime soon.  It
was taking around 5 seconds to start with 128 interfaces (ie, before
it forked and went into the background, for instance).  I'll take a look
at the eloop/poll code at that time as well, if no one beats me to it.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com