PULSE_CODE_DISCONNECT: cleaning up my own data

Hello,
I am having a problem when a task dies that has connected to my server.
I am storing information about the connected tasks within an internal table.
When a task sends a PULSE_CODE_DISCONNECT, I need to clean up my table.

I tried to use ConnectClientInfo to get the PID of this task by the received SCOID, but ConnectClientInfo returns always -1 (errno EFAULT).

struct _client_info client_info; if(ConnectClientInfo(new_msg_in->pulse.scoid, &client_info, 0) == -1) { printf("%d", errno); }

Why doesn’t ConnectClientInfo work? Is there something wrong with the client_info-Buffer?

Or other way round: Could I store the SCOID besides the PID in my table, so I could search for the SCOID when the connected Client dies?
Is the SCOID unique?

Thanks,
Mr.Green

Mr Green,

The scoid is unique otherwise you wouldn’t be able to close a particular connection between processes.

That said, it’s not clear why your code is indicating a fault with the ConnectClientInfo() call. The only plausible explanation I have (assuming your new_msg->pulse.scoid isn’t the issue) is that the process you are trying to get info for no longer exists because it already died. The easy way to test if that is the case is to do the same ConnectClientInfo() call when receiving a normal message and if that doesn’t indicate an error then you have your answer.

Tim

Good morning,
Of course I call the ConnectClientInfo() in that moment when the DISCONNECT-Pulse arrives, so I guess this information has been already removed?
When I call it when a normal Pulse arrives, it works.
But I don’t understand why: I don’t need to use the SCOID (at least at the moment) in another case than the DISCONNECT-Pulse arrives.

So how could I get the PID of the died task that has sent a DISCONNECT?

Regards, Mr.Green

Mr Green,

I don’t think you can get the PID of a process that has died because the process has already been removed from the kernel.

The normal DISCONNECT case when a process voluntarily disconnects is different because it still exists and so the kernel can give you its PID.

So your choices are:

  1. Store the scoid (as you pointed out in your initial post)
  2. Obtain the PID of the process when it initially connects and register with the kernel to be informed when that process exits and clean up that way (requires other API calls).

Tim