I am trying to set up a message passing system where a server replies to a client. The added twist is that the server, after receiving the message, should delegate the reply to another process. When I fork the server process, it seems I can only reply from the parent process, not the child process (the reply fails with “no such process”). The client is still blocked in REPLY. Any idea whether this is possible to do in the first place and if so, how to make that happen?
I don’t believe this is possible
See: qnx.com/developers/docs/7.0. … /fork.html
On the other hand it does say if you are using mqueue instead of QNX message passing that the child does inherit the mqueue message system so you could alternatively go that route.
Tim
I think this is right.
With QNX 6 in order to send a message (at least) three things need to occur first.
- The receiver needs to create a channel.
- The sender needs to find out the channel-id from the receiver
- The sender needs to create a connection to that process/channel.
#2 can be accomplished in two ways, by opening an attached name space, or with the name server.
A forked receiver process does not inherit the connection, so it can’t reply on it. A new thread however can.
A forked process does however inherit open fd’s.
In some version of QNX there was a “relay” call which allowed a receiver to pass a message on to another receiver who could then take over, but I don’t think QNX 6 does this.
If you have control over the senders, you could have reply message that instructs an api layer to resend to the new forked program.
I did this once with a database manager. The manager had a root process and a separate process for each open file. The API would first see if there was a file-process running. If not it would send its open call to the root manager who would create the process, and reply with the request to re-send the open.