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
