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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list