How can a resource man determine pid/chid of calling app

i have a resource man which i would like to send a Msgpulse to an app which has previously opened it. However the RM needs to ConnectAttach to the channel which the app has previously opened. to do this the RM needs the chid and pid in order to obtain the coid (using ConnectID).
First, is this correct?
Currently hte app passes this to the Rm using a standrad write(), but i don’t like having to send this info, and was hoping their was a more elegant way to obtain this info.


Using explicit messaging services between RM and appl. will shoot down the idea of RM. Probably, it is not a good thing to do!

No this is not correct. MsgDeliverEvent (which is what you use to deliver the pulse to the client app) does not required a coid, only the rcvid obtained when the client app initially sent the event.

It goes like this:

  1. Client initializes a sigevent struct.
  2. Client sends sigevent struct to RM.
  3. RM saves the rcvid and sigevent.
  4. When RM want’s to notify client, RM does a MsgDeliverEvent with the rcvid and sigevent struct.

I’ve looked at MsgDeliverEvent() and the example is clear but this would involve using two explicit (MsgSend & MsgDeliverEvent) message services. vishwa2000 mentioned that if using a resource manager model this is not a good idea. i’m interested in why this this is not a good idea.
In my case, the server is a ResMgr which has open(), read() & write(), however occasionaly on an external event the resource manager needs to pass a small piece of info to the client. the client should not have towait on this. The info easily fits into 32bits hence my orginal idea.
As mentioned above the resmgr uses only posix communication except when passing this info. Portablitiy is not an issue, this will always run on te same os and hw etc…
thanks for your advice…

Well, MsgDeliverEvent() is ment for exactly this purpose. First of all it allows the client to decide how to accept the information (signal, intr, pulse, etc). It also allows the server to perform an async. event delivery (ie: it doesn’t have to wait for the client). So it seems to me it fits with all of your requirements.

Thanks for your input. I will implement it this way then

Hi again,
I’m just starting to try this method and have a further question.
The server (in my case resource manager), should receive the MsgSend() fom the client in order to receive the pulse event info which he is interested in but which chid should be used i the Msgreceive call).
In the example (for MsgDeliverEvent() ), the chid is from a name_attach however my server is actually a resource manager. I know that the process man has the resource managers chid but how can i access this to use in the MsgReceive function?

You don’t need a chid for MsgDeliverEvent(), you need a rcvid. You can get the rcvid from ctp pointer in your callback.

In the example for MsgDeliverEvent()

( … event.html)
, the server receives the pulse event info from the client via a MsgReceive(), the rcvid which is returned from this function call can then be used in the MsgDeliverEvent() function parameter list.
My question concerns the chid which is passed in the MsgReceive() call

You don’t need to worry about that in a resmgr. The main dispatch loop handles the receiving of the messages for you. Either use a devctl() handler or a message_attach() handler.

Ok, so if i imp a devctrl function in the resmgr. The client can send the server the pulse in the io_devctl_t struct.
The resmgr will use
int devctl (resmgr_context_t *ctp, io_devctl_t *msg, RESMGR_OCB_T *ocb);
He will receive the type of pulse to receive in the msg, and from your earlier post, he can find the rcvid from the ctp pointer (ctp.rcvid).
He can then send the pulse event in a MsgDeliverEvent(rcvid)
Is this correct?

The proper step is:

  1. client create a channel (name_attach(), dispatch_create(), ChannelCreate())
  2. client connect to his own channel to get a coid (ConnectAttach(), message_connect())
  3. client prepare a sigevent, make it a Pulse, with the coid in step 2.
  4. client send this sigevent to server (maybe add some extra info like:
    if <condition X happened, send this sigevent back to me)
  5. server received the sigevent, remember it, together with the rcvid, then MsgReply()
    it back.
  6. client go on do it’s own work, and leave a thread MsgReceive() on the channel it
    created in step 1)
  7. sometime later, server (RM) find “condition X happened”, it then do a MsgDelieverEvent()
    with the saved rcvid, and the sigevent.

Thanks to cdm & xtang i now have this working correctly!!!

Great to hear, however, except for (the somewhat tangential to the discussion) steps 1,2 and 6; what xtang posted are the exact steps I originally posted ;-)

You are of course quite right!!!
This is what you correctly stated, 3 weeks ago!!
I was confused at the time as to how the MsgDeliverEvent() example related to my situation with the client sending a msg tot he server.

A big shout out to rgallen too :smiley: