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

["Daniel P. Berrange" <berrange redhat com>]

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. 

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.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|