Re: ORBit2 asyncness ...

[Michael Meeks <michael ximian com>]

Hi Dave,

On Mon, 2002-09-09 at 21:13, dahaverk@rockwellcollins.com wrote:
>  My thought is why hasn't ORBit-mt been merged into ORBit?

	ORBit itself or ORBit2 ? there are no changes happening on ORBit since
it's hard bin-compat frozen, and I believe it can't be done easily with
that structure.

	I'm hoping it can work better with ORBit2.

>  I'm actually just starting to look at ORBit-mt...  We had some serious
>  performance problems when we tried ORBit on our embedded target.

	Hmm; that's bad. I do think asynchronous stuff will help you a lot more
than the complexity of the CORBA threading stuff will hinder you.

>  Plus, the dependancies on newer glib versions etc for ORBit2 in the
>  configure are very unfriendly toward porting.  I hate it when you set an
>  option to be "no" such as "nls" in glib, then it changes it to a "maybe"
>  and then stops the configure when it doesn't find the NLS
>  includes/libraries.

	I believe this is a matter of not using config.cache properly in glib2
configure; can you badger Owen about that again on the gtk-devel list,
if it's seriously causing problems - then the way to have it fixed is to
file bugzilla.gnome.org bug reports, and send mail, please do.

>  Which brings to mind another question, does ORBit2 truely depend on
>  something that was fixed in the new version of Glib?... 

	I forget; we might use the static recursive mutex's, we certainly use
GObject in 'linc' which wasn't available in glib 1, so it's unlikely to
work well with glib1.

	But really - there's a patch in bugzilla to make glib use config.cache
nicely I think; so it shouldn't be a massive problem no ?

> Or was the
>  configure dependancy just to force someone to update their "glib" because
>  Glib development has been moving forward and they've ratcheted their
>  version.

	Both; either way, a morass of conditionals is not helpful to anyone at
the end of the day, it creates a myriad fragmented binary incompatible
platforms ;-) [ but then that's not a problem for embedded systems I
suppose ].

	Either way - I think the async code is more useful than threading, and
I believe Sebastian agrees [ having done the work on glib2 to make it
more thread safe ].

	Regards,

		Michael.

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