[PATCH 1/2] [0.4.8] eloop extension for dbus control interface, v2

[Jouni Malinen]

On Mon, Apr 17, 2006 at 10:30:04AM -0400, Dan Williams wrote:

> Ok, the reason I was hoping to be able to pass in the signal type is so
> that users wouldn't have to have 3 different dispatcher functions just
> to process signals.  So the (messier) alternative here is to remove the
> passing of the EloopEventType parameter into the callback, and require
> eloop users to register a different function for each type of event
> instead of being able to use the same one for everything and put a
> switch() statement in it.

Yes.. Though, you would need to register all types separately anyway, so
the main difference would be in having couple more functions.. In some
cases, this can actually enforce more cleaner separation of the
handlers.. ;-)

If the additional argument is desired, it can be done by adding a flag
for each registered handler to indicate which version is used and then
having two calls in the event dispatcher (i.e., the handler function
pointer is type cast there depending on this flag). This would end up
allowing the same interface as your current patch is using, but the
eloop implementation would be bit more complex due to the additional
flag and this would use some more memory.

I think I'd prefer to use the old handler type and get rid of all the
type casts for function pointers. Yes, this means that one will need to
have separate functions for each event type, but I kind of like this
;-). Keeping the eloop code more understandable is also nice point even
though most people don't need to look at its details.

-- 
Jouni Malinen                                            PGP id EFC895FA