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

List:       kde-devel
Subject:    Interprocess Communication...still a little confused
From:       Ryan Bean <rbean () lycoris ! com>
Date:       2003-07-08 17:34:41
[Download RAW message or body]

Adriaan:
Thanx angain for your input.  I thought I should mention that I'm a windows \
experienced programmer.  I'm a little new to 'K'stuff.  I had never even heard of \
DCOP before.  I do understand the advantage and resourcefulness of event driven apps, \
but I don't see how KApplication::exec() works.  To save you time, is there a handy \
resource I can go to to consider an example.  Can I call exec right at the begining \
of my main, and if I do, how is anything following called, and how is anything an \
'event' in terms of the exec() ?  I unfortunately  just don't see where it fits \
together.  Also, if you recognize the threads below, consider that app 'a' must wait \
for 'b' to start.  'A' is like a boot process for 'b' to run correctly.  I don't care \
if 'a' does nothing for a week until 'b' starts.  Again, thanx for your patience with \
this, I do apprecaite it.

PS: refering to the comments below...I never explicitly call dcopClent()::process, I \
was just trying to show what would happen on 'b' side from a send from 'a'.  And in \
my example of start()..send(), you said it was a linear way to do it, where else \
would I put send()?  It's part of a function that spawns the 'b' process.

Ryan Bean
Software Developer
Lycoris.com

Hi Ryan,

On Mon, 7 Jul 2003, Ryan Bean wrote:

> > I truly aprreciate your reply, and I can see that it must have the
> > correct answer, I just dont see exactly how.
> > This is what I have:
> > 
> > class MyApplication : public KApplication, public DCOPObject
> > {
> > Q_OBJECT
> > K_DCOP...
> > 
> > App 'a' forks 'b' with KProcess::start().  Both use MyApplication and
> > dcopClient()->registerAs(...).
> > Consider the following
> > //in 'a'
> > KProcess::start()  //you get the jist
> > MyApplication::dcopClient()->send(..) //info to 'b'
> 
> 


That's a very linear thing to do. You really should be working in a more
event-driven fashion. In other words, just start process B (BTW, it's
"gist"), and leave it be. You don't have to explicitly wait for anything
from B after starting it. Go back to the main event loop (you know, the
one started by KApplication::exec() that you never see) and wait for
events to be processed. If B starts up by sending a DCOP message to A,
then A's main even loop will pick it up and call the corresponding DCOP
handler.


> > ...
> > 
> > //in b
> > 'b'->MyApplication::process( ... ) //the K_DCOP interface
> 
> 

I've never seen ::process() called. It even makes me suspect that you're
rolling your own event loop instead of calling KApplication::exec().


> > However, if I do this:
> > 
> > //in 'a'
> > KProcess::start()  //you get the jist
> > KMessageBox::information(NULL, "click <OK> when 'b' is started");
> > MyApplication::dcopClient()->send(..) //info to 'b'
> > ...
> 
> 


Again, this suggests that you're not programming in an event-driven style,
but in "old fashioned" linear style. If you _really_ want to do that,
consider: is DCOP (very event-driven) the right communication mechanism?
Somebody else on -devel suggested that you write to B through stdin/stdout
instead of using DCOP. Then you can ::start(), write, write, etc. Don't
forget about the GUI blocking while you do that, though. See, B has a
non-zero startup time, perhaps several minutes on a loaded system, and you
don't want the GUI to block totally while A waits for B to start up.


> > Furthermore, if I can't use sleep, how can I efficiently make the app sit?
> > Also, KApplication says is sends the signal shutDown when the app is
> > done.  However,
> > My app gets this signal after every messagebox.
> 
> 

You make an app sit efficiently by returning to the main event loop. That
uses select() to wait on X events, socket events, DCOP events, and what
have you. So there's no penalty there. If you're getting shutdown signals
all the time, it again suggests that you're not using the
KApplication::exec() call to enter the main loop, but are programming in
linear, non-event driven style.


> > In closing, you mentioned that I should use the .kidl stubs and that I
> > implement the method applicationBIsReady from AppADCOP and have it use
> > QTimer::singleShot(10,this,SLOT(sendDataToB()));  My question is: what
> > is sendDataToB, and how does A receive it?
> 
> 

Well, sendDataToB() is a function that sends some of the data that A has
ready and wants to send to B, to B. It is a slot in application A (a slot
so QTimer can connect to it) that calls a DCOP function in B's interface -
like, say, hereIsSomeDataFromA(QString, int, QImage). B receives it by
implementing the DCOP interface function hereIsSomeDataFromA() and does
whatever with the incoming data.



-- 
Ryan Bean
Software Developer
Lycoris.com


 
> > Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


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