Talk:Rendezvous
This task is problematic to attempt because its description is currently tied very closely to how Ada conceives of it to be done. —Dkf 18:57, 12 May 2009 (UTC)
- From the birth of it I am wondering if using dbus would be possible to achieve the same purpose and being task compliant... and why not named pipe...? or simply a socket...? Is a synchronous "echo server" (like Echo Server, but synchronous as said) usable in the same way a rendezvous can be used? (Just throwing questions as usual:D) --ShinTakezou 13:32, 14 May 2009 (UTC)
- If I remember right (and it's a few years since I studied this) with the “Rendezvous” communication style:
- The sender sends a message and waits for the receiver to reply; will only commence execution once the receiver responds.
- The receiver can choose when to accept the message and how to respond to it.
- Sender and receiver are synchronized (with sender idle) for the duration of the processing of the message. It is from this synchronization that the name “rendezvous” originates.
- It has a lot in common with the communication model in CCS, except (of course) for the fact that values are passed as arguments and returned as a result.
- I do not remember if Ada allows accepting of messages dependent on what the values of some arguments are, but other (admittedly much more obscure) languages do allow such things within the general communications model; it's a language feature, not a communications feature.
- I believe the sender can't formally constrain how the receiver responds.
- Does this (rather sketchy) summary help? —Dkf 08:07, 19 May 2009 (UTC)
- If I remember right (and it's a few years since I studied this) with the “Rendezvous” communication style:
- Sender: SendMessage(port, msg); Wait(port); ... (get the answer, do something ecc.)
- Receiver: loop... for some reason, at some point: GetMessage(port, msg); if (msg != NULL) { do something with the message, prepare an answer, SendMessage(port, answer); } ...
- This can be done, and should keep the task synchronized through the communication "port"; but of course there nothing like "arguments" passed or returned... there's a "message" flying from A to B and viceversa. it's a language feature, ... means it can't be implemented (as the task requires it) in e.g. C?
- Yes helped thanks, but I am always full of doubts... still without any idea about which languages I know can do that "as language feature"... currently I believe none of "mine". --ShinTakezou 15:50, 20 May 2009 (UTC)