Re: BonoboUnknown & G_SIGNAL_TYPE_STATIC_SCOPE

[Michael Meeks <michael ximian com>]

Hi Guys,

On Thu, 2002-01-03 at 02:17, Tim Janik wrote:
> > People just have to learn to always use G_SIGNAL_TYPE_STATIC_SCOPE;
> > doing it magically for one type doesn't help.

	So - the consensus is that this should go; so I will accept a patch set
for libbonoboui, libbonobo, and an LXR search to add this
G_SIGNAL_TYPE_STATIC_SCOPE - everywhere this type is currently used.

	Otherwise it stays.

	Owen's idea for a per Box ref count is a good one; to force a static
scope always; but the whole thing makes me so unhappy that it's just not
true. We should go for the suffering option of typing loads and loads [
of course, a BONOBO_TYPE_UNKNOWN_FOR_SIGNALS would perhaps be an option
if the API wern't frozen ... ].

> also, by convention, NAMESPACE_TYPE_OBJECT should reveal the _type id_ of an
> object

	Of course.

> > > 	No - sadly not; the way the reference counting convention was
> > > constructed does not allow us to distinguish when a Bonobo reference is
> > > being handed, and when a 'weak' or CORBA only reference is being passed.
> > > Thus it is not possible to reliably cache the Bonobo_Unknown reference
> > > count - sad but true.
> > 
> > Hmm, yeah, forgot about that problem. 
> 
> we discussed this some with michael and stefan westerfeld last guadec, since
> bonobo is by far not the only scenario that brings this up, basically the
> only reliable ways are:
> 
> 1) use pure proxy types remotely
> 2) keep a list of remote object references with the connections (sockets)
>    as they come in. basically, this is making the incomming connection
>    the entity owning remote references, so once it vanishes things get
>    cleared up correctly.

	All of these schemes ( and more ) are scuppered by not having the
distinction I referred to above [ with which ref counting would be
somewhat drasticaly more tenable from many perspectives ]. Also
connection based ref counting, results in acute problems during
reference transferal and we would need major ORB hooks to be able to
track references reliably. Furthermore the 'oaf' model of activation
doesn't lend efficiency to making connection based distributed ref
counting a reality - since all referencing of remote objects would have
to via Oafd. 

> for (1), C is unfortunately not good enough to make this conveniently
> transparent, and to implement (2) orbit (CORBA) doesn't offer the required
> hooks (as far as i'm told).

	There are no problems adding this type of ORB hook really - but we just
don't have enough information to solve the problem.

> well, yes and no, one of the things i've got on my list for some time now
> is writing a mechanism to mirror/sync types remotely and transfer instances
> across process borders. this has many potential uses, such as
> - generating automated GObject bindings from IDL systems that provide
>   sufficient introspection mechanisms (CORBA, MCOP)
> - doing object system manipulations (like GUI builders) remotely
> - dispatching notification signals remotely or asyncronously (kinda like
>   an event queue)
> - make living objects persistent

	Sigh - I very very much wish you had used the ORBit code or a CORBA
compatible methodology for your value system - it's a travesty to be
striving mightily to map between two Free type systems that have been
written independently. My feeling is the best thing to do is to write
bindings for both for scripting languages and have done with it - let
the bridge be implicit in each binding.

> > Which would be improper normally since if set_font() was
> > called again, the old_font parameter would be come invalid.
> > It's adding some automatic protection against reentrancy
> > problem.

	Sure - I can see it's useful sometimes; just as an always on default it
doesn't help me here.

> the signal system is a whole different (alive!) beast, the majority of
> data (handlers, closures, emissions, invocation hints) it uses/accesses
> and manages is modifiable and changes frequently, which is why there's
> one global mutex protecting it all.

	Incidentaly; could we be using g_alloca for eg. g_signal_emit_valist's
GValue 'free_me' list ? also since locking is somewhat expensive - would
it not be more expeditious to copy the param types array to a g_alloca'd
area per emission - than do a lock / unlock pair per argument per signal
? NB. Threads are enabled in pretty much every Gnome app due to
gnome-vfs.

	Also - I wonder at that locking, is it neccesary ? can signal's
parameter types be changed dynamicaly ? and if so - why ? what's the
point ? you're going to get pretty stuffed unwinding a stack frame when
the types change underneath you - I mean if someone changes the type of
arg2 from boolean to double as you are walking an emission with
'boolean' then you're pretty stuffed.

	I wouldn't mind - but I hear rumours of slowness in the signal code
around there.

	HTH, I look forward to a patch set from someone ultra motivated,

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot