number of workspaces : mcs dialog vs. desktop window menu

[Brian J. Tarricone]

On 11/03/04 21:24, Jasper Huijsmans wrote:
> Brian J. Tarricone wrote:
> >On 11/03/04 12:38, Jasper Huijsmans wrote:
> >
> >>On Wed, Nov 03, 2004 at 12:17:27PM +0100, Olivier Fourdan wrote:
> >>
> >>>On Wed, 2004-11-03 at 11:55 +0100, Jasper Huijsmans wrote:
> >>>
> >>>>On Tue, Nov 02, 2004 at 01:29:06PM -0800, Brian J. Tarricone wrote:
> >>>>Ok, updated xfce-mcs-manager to unload modules before exit and xfwm4 to 
> >>>>re-add
> >>>>the dynamic workspace change handlers.
> >>>>
> >>>>Seems to work properly, but I don't think I saw the problems with it 
> >>>>last
> >>>>time, so it could do with some testing.
> >>>
> >>>The problem arised when we renamed the workspace plugin, two plugins
> >>>managing the same channel were loaded. Therefore, the second was
> >>>unloaded, but the callback was still active and pointing to dead code
> >>>(which I see as a serious security issue)
> >>>
> >>
> >>Yes, indeed. That is definitely fixed now. The only thing I'm not sure 
> >>about
> >>it what happens when the manager is killed forcefully with 'kill -9'. The
> >>netk_screen object is global so it still exists.
> >
> >
> >not sure what you mean by that.  if you kill the mcs manager, it's gone,
> >as is any memory that belonged to it (including the netk_screen).  there's
> >no such thing as a "system global" variable or whatnot.  or am i missing
> >what you're asking here?
> 
> Yeah, I supose you are right. The netk_screen is as a singleton object 
> per screen (AFAIK), so I was wondering what would happen if you closed 
> the app without disconnecting the handlers.

yep.  it's a singleton only within xfce-mcs-manager's process space.  any
other app that uses it has its own copy, with its own signal connections
and whatnot.

	-brian