[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] Using virtEvents



Daniel, Eric

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 
exits right away.

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
lldpad yet.

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

Regards,

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]