> Mario Charest wrote:
> >  Would it make any sense to a done state to the typical SRR.
> >
> >  Currently the receiving end can get a header, figure out the size,
> >  allocate the memory and receive the rest of the data. But that is not
> >  possible for the reply.
> >
> >  MsgSendReply (block until reply received) MsgReceive MsgRead
> >  MsgReply, blocking MsgSendReply ( unblock ) MsgReadReply  (read rest
> >  of data ) MsgReadDone ( indicate we are done) MsgReply unblock.
> >
> >
> >  With QNX4 it was somewhat simple to implement something like this on
> >  top of the existing API.  Simply two SSRs in a row. A first to send
> >  the command and get the size of the reply data. Memory area is grown
> >  or allocated for the reply and then another SSR is done to get the
> >  data.  Receive() takes the pid argument which make implementation
> >  easy because one can make Receive only wait for message from one
> >  process leaving.
> >
> >  With QNX6 implementing something similar looks quite complicated.
> >
> >  Suggestions?
> 
> Isn't this just about establishing a protocol between client and server?

You could say it is but the implementation becomes very cumbersome, the problem is the whole think becomes asynchronous.
 IF the message is split into two message, the client which can also receive other messages then the one send by the 
server, must keep track of the pending message, implement timeout in case the server dies etc.  It's also very hard to 
hide the implementation inside a cover function for MsgSend.

> One implementation (assuming this is done frequently and with some
> significant data payload) would be to use messages as a triggering
> protocol on top of a block of common shared memory.

Nah, need to work across network.

> 
> * The initial send gives the shared memory location information,
> * The server ensures visibility into that shared memory area before replying
> and examining data in the shared memory block that (may) contain a shared
> synchronization primitive
> * The client does its thing with the shared memory area and either signals
> via the shared memory that the action is finished or via a 'done' message.
> 
> That is how I've done it in the past with other customers.
> 
> Thomas