On Jan 5, 2012, at 6:35 PM, Daniel P. Berrange wrote:

Thank you very much for the introduction, I've spent the

week digging through the code and have a way better

understanding of the difference in the handling of events

now.

Any event loop callback must be sure to complete in very
fast time, since all I/O processsing is blocked while an
event callback is running. So typically callbacks would
restrict themselvs to reading/writing I/O on the triggering
file descriptor, or some other small non-blocking piece of
worker.

If your event loop callback intends to invoke complex
APis, which may in turn need to do I/O, then you must
spawn a new thread so that you don't block the whole
event loop.

I agree. I want to add a netlink socket interface to libvirtd

through the event handler interface.

The callback itself then receives the netlink message

and passes it to its own registered netlink event callbacks.

Since most netlink messages to libvirt do little more than trigger

a log entry or cause a lldpad message they return almost immediately.

More complex functions will receive the message fully, and can

then detach themselves as threads.

For a start I'll add a callback into the macvlan setup function, if

a 802.1qbg link goes down it receives a message and adds a

log entry. When the link goes back up it re-sends the associate

netlink message to lldpad. It does not wait for confirmation but

I have most of the code ready and working - but I still need to get

the lldpad message decoding done because this is not finalized in

... but I'd like to know if you see any showstoppers in here.

D.Herrendoerfer <herrend at de dot ibm dot com > <d.herrendoerfer at herrendoerfer dot name>