Re: Orb choosing time (was Re: Adding other languages to omniorb)

[Owen Taylor <owt1 cornell edu>]

edgehp@together.net writes:

> On 22 Jan, Maciej Stachowiak wrote:
> >
> > You can make the gtk event loop non-blocking by adding an idle
> > function. I don't know about CORBA, but I would be very surprised if
> > there were no way of getting around the blocking effect above. After
> > all, it is supposed to be useful on, e.g., the MacOS, where every app
> > has a GUI with an event loop and thread support is poor to
> > nonexistent.
> >
> The question isn't whether or not you can avoid threads. Of course you
> can.
> 
> The question is whether or not threads constitute a "natural" way to
> do what you need to do. For many situations, threads can simplify the
> logic and code. Conversely, using threads where they don't belong can
> obviously make it worse.
> 
> I'm not urging the use of threads here, I'm urging the consideration
> of threads.

I would agree that threads are something that we should be looking
toward in the future.

As soon as you have multiple clients making calls on each other
(through CORBA), many of the same synchonization problems occur
as you have in a single multi-threaded program, and some of them
are _solved_ by introducing threads into the program.

For instance if client A calls client B, and, in answering the
request, client B calls client A, if client A is single threaded you
have a deadlock. But if client A is multithreaded, it can answer
the request, and things continue.

But the other way of looking at this, is that using threading 
introduces all the problems of distributed programming into
programming a single client. Using threads requires some
experience/knowldge of the pitfalls that can occur, and quite
a bit of discipline. 

So I think we may want to use threads for some things, but
certainly shouldn't be using threads just for the sake of
using threads.

But if we ever want to use threads, the lack of threading in MICO is a
serious disadvantage. An ORB is a program that has to do a lot of
synchronization, and retrofitting after the fact is not going to be
easy. (If you have a taste for complexity, take a look at ILU's
mutexes. Of course, ILU also has a lot of complexity in reducing
blocking as much as possible when single threaded.)

Regards,
                                        Owen