I fully understand the Send/Receive/Reply services, but can somebody explain
to me how the kernel knows what thread to Reply back to in a Process full of
threads.
example
Client A has 3 threads. Thread A1 sends a message to Server B, then A2
sends a message to Server B. How does Server B know to reply back to Thread
A1, and not A2?
Im guessing it has something to do with the _msg_info structure that can be
received with a MsgRevieve() call, and also that the kernel is super smart.
Demian (damient@wave.home.com) wrote:
: I fully understand the Send/Receive/Reply services, but can somebody explain
: to me how the kernel knows what thread to Reply back to in a Process full of
: threads.
: example
: Client A has 3 threads. Thread A1 sends a message to Server B, then A2
: sends a message to Server B. How does Server B know to reply back to Thread
: A1, and not A2?
: Im guessing it has something to do with the _msg_info structure that can be
: received with a MsgRevieve() call, and also that the kernel is super smart.
MsgRevieve? 
It has to do with the receive ID that’s returned from MsgReceive.
For example:
(server.c):
while (1) {
rcvid = MsgReceive (…
// do stuff here
MsgReply (rcvid, …
}
Is a typical server loop. In the client, three threads as in your example
can all send a message to the server. The server will get three different
values for the “rcvid”. that’s what’s used to track “to whom” the reply
will go.
Does that help?
Robert Krten, PARSE Software Devices; email my initials at parse dot com
Consulting, Systems Architecture / Design, Drivers, Training, QNX 4 & Neutrino
Check out our new QNX 4 and Neutrino (QRTP) books at http://www.parse.com/
Wanted PDP-8/9/10/11/12 Systems/documentation/spare parts! Will trade books!
Previously, Demian wrote in comp.os.qnx:
I fully understand the Send/Receive/Reply services, but can somebody explain
to me how the kernel knows what thread to Reply back to in a Process full of
threads.example
Client A has 3 threads. Thread A1 sends a message to Server B, then A2
sends a message to Server B. How does Server B know to reply back to Thread
A1, and not A2?Im guessing it has something to do with the _msg_info structure that can be
received with a MsgRevieve() call, and also that the kernel is super smart.
This is really quite simple. The kernel has a table of all
processes + threads. When Thread A1 sends a message to
Server B, Server B receives a connection ID that refers to
Thread A1. When Server B Reply’s, the Kernel knows who to
wake up because of this connection ID.
Mitchell Schoenbrun --------- maschoen@pobox.com
Mitchell Schoenbrun <maschoen@pobox.com> wrote:
Previously, Demian wrote in comp.os.qnx:
I fully understand the Send/Receive/Reply services, but can somebody explain
to me how the kernel knows what thread to Reply back to in a Process full of
threads.example
Client A has 3 threads. Thread A1 sends a message to Server B, then A2
sends a message to Server B. How does Server B know to reply back to Thread
A1, and not A2?Im guessing it has something to do with the _msg_info structure that can be
received with a MsgRevieve() call, and also that the kernel is super smart.
When you receive the message, MsgReceive() returns a rcvid. When you reply,
you pass the rcvid to the MsgReply() call. This rcvid uniquely identifies
the specific MsgSend() call the reply will go to. It identifes nd/pid/tid
for the reply.
This is really quite simple. The kernel has a table of all
processes + threads. When Thread A1 sends a message to
Server B, Server B receives a connection ID that refers to
Thread A1. When Server B Reply’s, the Kernel knows who to
wake up because of this connection ID.
No, coid are a process level resource – multiple threads in the same
process can all be sending using the same coid.
QNX Training Services
dagibbs@qnx.com