🚀 go-pugleaf

In article <1992Nov20.205516.1211@csi.uottawa.ca>  
isabelle@shamin.genie.uottawa.ca (Isabelle Tourneux) writes:
> 
> First, thank you very much for all the detailed answers you have
> given me concerning message queues. This has however led me to
> other questions :
> 
> I have several adew "view+controller" in the same machine, which
> are spawned successively with forks and execs. I would like to have
> them communicate with each other. So I have looked at all the
> possible means of communication between these controllers. I am
> using System V.

Which System V?

> - interruptions would be a nice solution, but I have not managed
> to get the pid of the controller without clicking somewhere on the
> view. A getpid() in controller_go gives the pid of runadew I guess.
> Moreover, runadew puts the group id of the controller equal to the
> pid of this controller, so I cannot get the group id of the
> controller without clicking on the view, as for the pid. Is it
> possible to change the code of runadew to prevent it from
> initializing the group id of the controller ? Do you think
> interruptions would work as I am working under System V and Xwindows
> ?
I assume you mean "signals" when you say "interruptions." Depending on the  
version of System V you are using (i.e. you want reliable signals) it might  
be possible to get this to work. My personal philosophy is that signals are  
best used for exceptional conditions and should be avoided for other things.  
Mostly due to the difficulty of debugging asynchronous code, but also due to  
really bad experiences with kernel bugs involving signals.

> 
> - I know sockets would be a solution, but I would prefer not to
> use them for internal communication between processes runing on
> the same machine : I am afraid I will not be able to send a huge
> file through a socket without cutting it into smaller parts, and I
> would like to avoid that. Do you think Unix Domain Sockets could
> allow me to send huge file without cutting them ?

I have no idea why you claim this is a problem. Both UNIX domain and TCP  
sockets should work fine for this application. This would be my personal  
favorite.

> - as all my controllers have got different names, I have thought
> about memorizing the pointers on each controller in a memory shared
> by all the processes :
>  struct controlleri * ptri ( i = 1, 2...),
> and call functions of a controller from another controller, using
> this pointers : controller1_thisFunction(ptr1) in the code of the
> 2nd controller for instance.
> The 1st controller is running, but the function is not called
> successfully, and there is a segmentation fault. Before, I had
> never had problems with memorizing pointers on an ATK view or
> dataobject in another ATK view or dataobject, and calling
> functions with these pointers. Is there something specific to adew
> which prevents from doing that ? 
> 

I don't know enough about ADEW to understand this question.

>                          I am trying at any rate to establish a
> communication between Adew controllers, but it is hard because adew
> and runadew were not written for that kind of application, but were
> supposed to be used only for prototyping. Anyway I really want to
> find a way of establishing these connections, even if the solution 
> is not the most elegant.

I guess my high level answer would be that you want an RPC package to ease  
communication between separate processes. If nothing else some sort of name  
service seems in order. Of course that may be too much work. The simple  
method is to drop a bunch of port numbers into a file all the processes can  
access and use sockets for communication. Be sure to use proper locking  
discipline on the file.

> 
> Thanks for your help.
> 
> isabelle Tourneux
> Multimadia Lab of the University of Ottawa.
> isabelle@shamin.genie.uottawa.ca

--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  "Yeah. Ask 'em if they'll upgrade my shifters too." Bill Watterson