View topic - Delegating message reply to another process

Delegating message reply to another process

anything that doesn't fit to other groups.

Delegating message reply to another process

Postby tkunz » Wed Aug 08, 2018 10:12 pm

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?
tkunz
New Member
 
Posts: 1
Joined: Wed Aug 08, 2018 8:21 pm

Re: Delegating message reply to another process

Postby Tim » Thu Aug 09, 2018 10:10 pm

I don't believe this is possible

The child process doesn't inherit any timers, QNX Neutrino message-passing objects, side channel connections (coids), or channels (chids).


See: http://www.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
Tim
Senior Member
 
Posts: 1420
Joined: Wed Mar 10, 2004 12:28 am

Re: Delegating message reply to another process

Postby maschoen » Fri Aug 10, 2018 9:30 pm

I think this is right.

With QNX 6 in order to send a message (at least) three things need to occur first.
1) The receiver needs to create a channel.
2) The sender needs to find out the channel-id from the receiver
3) 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.
maschoen
QNX Master
 
Posts: 2682
Joined: Wed Jun 25, 2003 5:18 pm


Return to General Programming

Who is online

Users browsing this forum: Google [Bot] and 12 guests