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
Ok
Ok
and with 'pr' I get the same thing:
: (hear (pipe (do 3 (wait 2000) (pr '(println 'Ok)) (flush))))
-> 3
: Ok
Ok
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,
Tomas
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
