[patch] Add eloop support for write & error socket callbacks

[Jouni Malinen]

On Tue, Mar 21, 2006 at 10:26:52PM -0500, Dan Williams wrote:

> DBus, at least, uses the socket and select model anyway, which fits in
> nicely here.  What OSs don't have select, other than some random
> real-time ones?  What does moving off select() actually gain?  In any
> case, if we don't have read/write/error, we'll need to figure out some
> way to kludge that in.

Windows does not allow select() to be used for everything and
wpa_supplicant 0.5.x is using WaitForMultipleObjects() in eloop_win.c
because of this. WSAEventSelect() allows number of different event
types, including read and write, so I'm not too worried about this.
PalmOS is another examply I've seen and that was require quite a bit of
hacking on this front. In addition, we need to keep in mind that
wpa_supplicant is indeed being used on number of those "random real-time
ones"..

By the way, that "error" should probably be renamed to "exception". I
don't know what it is used for with dbus, but I would assume that this
could be used for other things than just errors.

> Underneath, dbus opens a UNIX domain socket to the dbus daemon, and the
> user (in this case wpa_supplicant) needs to monitor that socket for
> read/write/error states.  So if there's some other mechanism used rather
> than select(), the dbus code would still have to use select in some
> fashion to even think of working.  We'd end up essentially polling that
> socket anyway.

Yes, as far as dbus is concerned, this should be fine. I just try to
keep the eloop interface generic enough to handle most cases and this
means trying to avoid OS or single functionality based exceptions
whenever that is reasonable.

> > Indeed.. I would not accept this if all places using eloop would need to
> > be changed. However, it should be possible to add a new function for
> > doing the registration as long as the existing API is implemented as a
> > wrapper on top of this new interface. This would allow new code to use
> > the new function while the old code would still work as-is.
> > 
> > Using a single function for this and maybe even changing the callback
> > functions to include an extra parameter, event type, could be a cleaner
> > solution for this. There would be only one eloop_sock_table and it would
> > have bitmask of which events (read/write/error) are registered to be
> > received.
> 
> Is this a prerequisite for accepting the patch?  Seems fairly easy, so
> I'll try that.

I wouldn't say prerequisite, but this would be highly preferred. eloop
is used in number of programs and just like the driver wrapper API, this
is something that should not really be modified frequently. In other
words, if this patch went in, it would be more difficult to get rid of
the new functions any time soon.. Having a more generic way of
registering more than just three events may also end up being useful if
there is need to support something additional in the future. If this can
be added without having to introduce new functions, it would likely fit
in more nicely.

-- 
Jouni Malinen                                            PGP id EFC895FA