Re: ORBit2 asyncness ...

[<dahaverk rockwellcollins com>]

I have to agree the "async" code will be more usefull.

I keep picking away at the compatibility problems between ORBit and MICO.

Yes I was refering to ORBit.     It seems strange to have an ORBit-mt
version on Source forge....  Even though ORBit is "frozen" it would seem
reasonable to merge the ORBit-mt stuff.  Fewer different specializations.


-Dave




Michael Meeks <michael@ximian.com> on 09/10/2002 04:33:49 AM

To:    David Haverkamp <dahaverk@rockwellcollins.com>
cc:    markmc@sun.com, orbit <orbit-list@gnome.org>

Subject:    Re: ORBit2 asyncness ...


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