Hi Alex,

> as in 'open'. Therefore, I would rather reduce the functionality of
> 'hear', so that from now on it only accepts a file descriptor (and no
> longer a symbolic argument). I'll write it into the ReleaseNotes.

I see, thank you.

> You tried to use 'rpc' to send messages to the other
> philosophers. While this is basically a correct idea, 'rpc' is not
> suitable in the current situation. It sends the message via standard
> output, and is intended to be used in a 'pipe' call.

What is the functional difference between 'rpc' and 'pr' and why the
specific constraint on 'rpc' being suitable only for stdout?

With 'rpc' I get:

: (hear (pipe (do 3 (wait 2000) (rpc 'println ''Ok))))
-> 3
: Ok

and with 'pr' I get the same thing:

: (hear (pipe (do 3 (wait 2000) (pr '(println 'Ok)) (flush))))
-> 3
: Ok

> If you look in the reference for 'hear', it says "hear is usually
> only called explicitly by a top level parent process". The reason is
> that upon a 'fork', the 'hear' channel is automatically set up in
> the child process to be used by the built-in IPC routines.

I see, where can I find this automatic channel, is it a named pipe?
If not, what channel is used for communication?

> As a consequence, if you re-open that channel with 'hear', the child
> is effectively cut off from its parent and could, for example, not
> synchronize on DB operations.

I noticed that 'tell' did not work for me when I opened the fifos, so
this is why:-)

> So the recommended and natural way is to use 'tell'. In combination with
> 'pid', it can also send messages selectively to other processes.

Using 'tell' I cannot send a message to the parent process though.  I
would like to have the philosophers talking to a monitor process which
cannot be the parent but must be another child for 'tell' to work.  Is
that correct?  How are children supposed to communicate with the
parent process?

> As an example, I modified your "phil.l" (I hope I understood it). Each
> philosopher (process) keeps the PIDs of his neighbors in the global
> variables '*LeftNeighbor' and '*RightNeighbor', and the state of the
> forks in '*LeftFork' and '*RightFork'. In the beginning, he waits until
> he received the PIDs from the parent process.

That's interesting, thank you.

'tell' seems to be asynchronous.  If I want to query the philosopher
processes about their state, I cannot use something like:

(de philState ()
   (list *Pid *State *LeftFork *RightFork) )

.. and in *Monitor process call...

      (let S (tell 'pid P 'philState)
         (println S)

because 'tell' does not return the result of calling 'philState'.  Is
there a standard/easy way of achieving this?

Thank you,

UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Reply via email to