Hi Eric,
Now that ticket that you have raised regarding this issue is closed,i will post the gist of your discussion with Robb and me here for any future references.
Ticket Summary:
In short C++ SDK is thread safe but not process safe. If your fork creates a new process, you can not access the SDK. If you are trying to implement the SDK on a forked child process, then you will need to initiate the SDK from within each forked process separately (including the appd_sdk_init() call), and all API calls must remain within the same process, you can not share BT or ExitCall handles across processes.Currently to determine whether the future SDK API calls should be accepted or not,it validates if the existing pid is the same as the one which issued appd_sdk_init call . But then if you try to call appd_sdk_init() call from a child process as well it might cause some corruption as SDK implements ZeroMQ messaging in the globally shared process space.Within each instrumented thread, the C/C++ SDK API uses ZeroMQ message buffers (and its underlying Unix sockets) to communicate to the Proxy task.
It should be possible to run two (or more) separate processes, both using the SDK API calls, provided they run completely independently of each other (i.e. do not share handles across process spaces). In other words, as long as each process makes its own appd_sdk_init() call, and use only handles created within that process space/sdk contex, (i.e. that they never share any handles between processes) then you should be able to implement the SDK in a forked process architecture.
Feel free to reach out to us in case you have more questions.
Thanks and Regards,
Sajna Sreenivasan
... View more
