On Tue, Jun 28, 2011 at 11:39:41AM -0600, Eric Blake wrote:
On 06/28/2011 11:01 AM, Daniel P. Berrange wrote:
If a callback being invoked from a stream issues a virStreamAbort operation, the stream data will be free'd but the callback will then stil try to use this. Delay free'ing of the stream data when
s/stil/still/
a callback is dispatching
* src/fdstream.c: Delay stream free when callback is active --- src/fdstream.c | 33 +++++++++++++++++++++++---------- 1 files changed, 23 insertions(+), 10 deletions(-)
cb(stream, events, cbopaque);
virMutexLock(&fdst->lock); - fdst->dispatching = 0; + fdst->dispatching = false; if (fdst->cbRemoved && ff) (ff)(cbopaque);
cb is called without locks, while ff is still under the lock. No change from previous status quo, but I wonder if ff should ever be moved outside the lock.
For the way the free callback is used, I dont think it matters Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|