I am using boost as communication framework in a library for Windows.
I am getting problems, when the client code, that uses our library, creates windows processes and inherits handles, e.g. by using popen(). I currently observing two problems.
Even though my library has closed the socket, the peer keeps an active connection.
When there is a pending async read operation, calling close() does not lead to the read handler being invoked with an error. My library closes a socket in its shutdown
process and because it also terminates the io_service during shutdown, it waits for the termination of the pending read operation.
The second problem is the one, that is visible to the client, since our library hands during shutdown. Unfortunately it is not triggered by just inheriting a socket handle to a child process. I know, the socket handle
gets inherited to the child process and when I kill the child process, the pending async operation terminates. I also have seen the pending read operation to terminate, then the peer system sends some data. The data seems to be read fine, although the socket
has already been closed by our library.
The io_service is blocked in the call to GetQueuedCompletionStatus() on its io completion port. It seems, the io completion port still is linked the the socket, although the socket has been closed.
The problem is triggered reliably, when using my fully integrated library, but I have not yet managed to write a small simple sand alone program to demonstrate this problem.
* Does anybody on this mailing list has a clue, what may cause the 2nd problem, where the async operation does not terminate upon closing the socket.
* Does anybody know of a reliable way to prevent an asio socket from being inherited. I found some web pages mentioning WSA_FLAG_NO_HANDLE_INHERIT, but have not found a way to get boots to use this flag other than patching
my boost source code.