Re: [gtk-vnc-devel] Problem with slow shutdown

[Anthony Liguori <anthony codemonkey ws>]

Daniel P. Berrange wrote:
> On Thu, Jan 10, 2008 at 06:02:43PM +0000, Richard W.M. Jones wrote:
>   
> > There's a similar problem to my previous posting related to shutting 
> > down the coroutine.
> >
> > For example, here is the sequence of events when my plugin is destroyed:
> >
> > NPP_Destroy		# called by the browser
> > calling vnc_display_close
> > Requesting that VNC close
> > Requesting graceful shutdown of connection
> > Waking up couroutine to shutdown gracefully
> > NPP_Shutdown		# !!browser could unmap code any time!!
> > Got all credentials
> > Auth failed
> > Doing final VNC cleanup
> > Requesting that VNC close
> > Releasing VNC widget
> >
> > Luckily the browser _doesn't_ seem to unmap the code, so this time at 
> > least it doesn't segfault, but there is no particular guarantee of that.
> >     
>
> Ok, so the bit where it says 'waking up couroutine' is supposed to
> switch into the VNC context. It only does that, however, if the VNC
> context is sleeping on g_io_wait_interruptable. 
>
> The logs show we're in the auth negotiation phase and almost 
> certainly sleeping on g_condition_wait, which isn't interruptable
> so we never wakeup  & abort the VNC context.
>
> I think we need to fix the g_condition_wait to be properly
> interruptable in same way as g_io_wait_interruptable works. 
>   

I guess everything would have to call g_condition_wait() in a loop also 
checking to see if there's an error raised?  Perhaps instead of 
returning -EAGAIN like g_io_wait_interruptible it could return a real 
error whenever has_error gets set?  Then you wouldn't call 
g_condition_wait() in a loop and just let the error fall through.

Regards,

Anthony Liguori

> With that done, the gvnc_shtudown() code should correctly switch to the
> VNC context, shut it down and then return to the main context before
> mozilla gets to do the NPP_Shutdown
>
> Dan.
>