Hello Gang,
I’m working on a resource manager and we’re using a mechanism described
in the MsgDeliverEvent documentation where you would have a client fill
out a sigevent struct and send it to a server for later notification on
some event. I’m just trying to understand why we need to provide a
connection id in the sigevent struct by calling ConnectAttach or
MessageConnect. Why do we need a connection to ourselves? When the
server receives the initial message with the sigevent, the server has
the recieve id from the message, so why are both the recv_id and coid
needed?
Thanks,
Eric
If the event is a pulse, the client will require a channel (and connection
to that channel) to receive the pulse on. This would be a separate channel
(not the servers channel). The recv_id that the server has is used to
identity the client, the kernel will then need the coid in the event
structure to figure out which connection to push the event on so the client
can receive it.
Connection ids have no meaning between processes so it is not enough to
identify the process/thread. And the recv_id has no association with the
channel that the client will receive the event on. So we need both to get
the event to the proper client. A coid is just like a file descriptor, it
only has meaning to the process/thread who opened it.
Regards,
Joe
Eric Norton <enorton_nospam@nospam_fct.ca> wrote in message
news:cnfv5i$71o$1@inn.qnx.com…
Hello Gang,
I’m working on a resource manager and we’re using a mechanism described
in the MsgDeliverEvent documentation where you would have a client fill
out a sigevent struct and send it to a server for later notification on
some event. I’m just trying to understand why we need to provide a
connection id in the sigevent struct by calling ConnectAttach or
MessageConnect. Why do we need a connection to ourselves? When the
server receives the initial message with the sigevent, the server has
the recieve id from the message, so why are both the recv_id and coid
needed?
Thanks,
Eric