> please tell me where the deadlock is. > As far as I know a deadlock arise when one process locks a > resource an other > process requests and vice versa.
A deadlock occurs when two or more agents are waiting for each other. Neither can make forward progress until the other does. This is precisely what can happen with your proxy and one or both of its endpoints. > Perhaps I misinterpret the SSL_pending You fundamentally misunderstand how to design a proxy. A proxy must never refuse to make forward progress, yet yours does. This can lead to a deadlock. Consider: A <-> proxy <-> B Asumme that B is trying to read from A. Assume A is blocked in 'write'. Your proxy *must* read data from A to allow A to make further forward progress. However, suppose your proxy is blocked trying to *WRITE* to A. A is trying to write to you and is blocked and you are trying to write to A and are blocked. Without the proxy, there would be no problem, because B would not blocking trying to write to A, and if it couldn't write, it would read, allowing A to unblock itself. So, in summary, a proxy must never refuse to make forward progress, or it can cause a deadlock. However, if your code reads 10 data bytes from A, it will not do anything else until it sends those 10 bytes to B. This is true even if it could send data to A at that moment. Thus your proxy can deadlock. When you design a proxy, it is absolutely vital that you never, ever wait for an endpoint in any case where you could make forward progress. Your code breaks this fundamental rule. As a result, you may wind up waiting for an endpoint that is itself waiting for you (to do something else, which you refuse to do because you're waiting for that endpoint to itself do something else). DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
