Hi,
> Yes, the code is prone to deadlock. The code implements the "I will not > start doing X until I finish doing Y" logic. This is known to cause > deadlocks in proxies, as one end or the other of the connection proxied > inevitably has an "I will not start doing Y until I finish doing X" logic. > > You thus wind up with a proxy that could make forward progress in one > direction but refuses to because it cannot make forward progress in the > other direction. 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. Perhaps I misinterpret the SSL_pending All I do is call select which tells me if I can read on the sockets/filehandles. If I can read from one or both endpoints without blocking I read the data and send it to the other endpoint. Write should never block on sockets I think? > But that's not your problem. You're problem is that you are horribly > abusing SSL_pending. SSL data may be neither in the socket buffer nor > pending, and you ignore it. (For example, the SSL connection may have, in > its buffer, an entire SSL protocol block. No data is pending, since the > first byte of the block has not been analyzed yet, and no data is waiting > on the socket.) The question is how will I find out that there is data I can read. Calling select is not sufficent? > In general terms, a general-purpose proxy can never say "I could do X, but > I won't do it *now*". You break this rule in two ways. One with > SSL_pending (which checks for one type of forward progress while ignoring > another) and by blocking in one direction even when you could make > progress in the other. > > DS > Greetings, Antonio
