[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Quick KOM/Corba Question
From:       Kurt Granroth <granroth () kde ! org>
Date:       1999-01-09 2:13:15
[Download RAW message or body]

weis@stud.uni-frankfurt.de wrote:
[CORBA/KOM question clipped]
> Seems you did not understand CORBA completely :-)

I agree :-)

> It does not matter wether stuff is in one process or in two.
> You can easily devide the example in two processes, but then it
> is not so easy to understand anymore.

Perhaps.  But using KOM and using CORBA are *not* identical.  I've been
trying to figure out what I need that is CORBA-general and what KOM takes
care of (see another post for more info on this).  A simple two process
example (like qthello in mico's examples) would have been invaluable!

I wrote:
> > App1:
> > void Receiver::slotClicked()
> > {
> > 	for(;;);
> > }
> > 
> > and
> > 
> > App2:
> > 	sender->clicked();
> > 	printf("Got here!\n");
> > 
> > With native signals/slots, you will never get to the printf.  Is there a
> > way that the slotClicked() function would be called in app2 but execution
> > would continue in app1?
> 
> Of course printf is reached! It is reached after slotClicked returns.
> What you mean is a oneway function. It implements somehow async
> communication but it is not fault tolerant any more. See the CORBA
> docu about "oneway".

Actually, printf is *not* reached in this example!  slotClicked() never
returns as it has a "forever" loop in it.  I'll definitely do some
reading on 'oneway', though.  Thanks for the pointer!!
-- 
Kurt Granroth
granroth@kde.org
http://www.pobox.com/~kurt_granroth

[prev in list] [next in list] [prev in thread] [next in thread]