Marc,

I understand you confusion in MsgDelieverEvent(). 

MsgSendPulse() and MsgDelieverEvent() is different.

MsgSendPulse() need a "connection", to sent the pulse; If your server
want to MsgSendPulse() to client, your server need to establish a
connection (via  ConnectAttach()) with the client (well, with the
channel created by client). To establish this connection, you need the
"nd, pid, chid", which, you need the client to tell you.

In MsgDelieverEvent case, you don't need a connection "from server to
client", it is the kernel that based on the rcvid, the event type
(PULSE) and the coid inside the event, to find out exactly HOW to
deliver event (in this case, add a pulse into the channel so whoever
MsgReceive() to that channel would get the pulse). Ie, the knowledge
about "pulse event", "connection" ... are all inside the kernel, not
your server application.

This is done so because as you can see, the "event" could be something
else. A signal, an indication of an interrupt... And the server could
designed in a generic way (just MsgDelieverEvent() without knowing
what's in the event), and let the client decided how they want to be
"notified".

Being said that, since a pulse event can carry 32bit "value", and
sometime it is necessary to have server carry back some value to client.
So for a server, knowing (by design) client will only sent "pulse
event", and modify the "pulse value" before MsgDeliever() it back.  It
is not so elegant, but I wouldn't say it's 
totally wrong.

Hope this making sense now.

-xtang


> -----Original Message-----
> From: Marc Roessler [mailto:community-noreply@qnx.com] 
> Sent: Thursday, April 30, 2009 4:49 AM
> To: ostech-core_os
> Subject: Re: RE: RE: Problems receiving pulses
> 
> Xiaodan, yes this is true, this would work using MsgDelieverEvent()...
> 
> But the problem is that in our case, the server needs to 
> modify a part of the event (the value) before sending it 
> back. Storing the client-supplied event in the (extended) OCB 
> and modifying it each time before sending it back to the 
> client is not so elegant...
> 
> So I'd rather try to do a MsgSendPulse() "manually".. and 
> also I'd like to get an in depth understanding of what (and 
> why) is happening internally, and this is a good chance to 
> learn about it.
> 
> 
> 
> OK... so if I wanted to use MsgSendPulse myself, the client 
> would send its chid and pid to the server. The nd and the pid 
> could be read from the ctp struct... is this also contained 
> in the ocb somewhere?
> 
> Then I would do on  the server:
> 
>   coid = ConnectAttach( client_nd, client_pid, client_chid, 
> _NTO_SIDE_CHANNEL, NULL); store this coid, and later:
>   MsgSendPulse (coid,priority, MY_PULSEID, 0)
> 
> correct?
> 
> Now what I don't understand: as we just saw, the server needs 
> client nd, pid and chid, in order to do a ConnectAttach() 
> before sending a Pulse. Then why does the client not include 
> this info in case we use Events (which are noting more than 
> an abstraction of the above code)? Instead, the client packs 
> his coid (!) into the event structure, and sends this to the server:
> SIGEV_PULSE_INIT( ®_msg.ev, coid, 
> SIGEV_PULSE_PRIO_INHERIT, MY_PULSEID, 0 ); This is what I 
> don't get, and how I got onto the wrong track regarding 
> coid/chid.. If the coid behaves like a file descriptor (i.e. 
> only makes sense in that specific process), why would the 
> client send it to the server?
> 
> And: isn't t the chid process specific as well?
> 
> Greetings,
>  Marc
> 
> 
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post28412
> 
>