On Jul 10, 10:57 pm, Wan-Teh Chang <[EMAIL PROTECTED]> wrote: > Yahel Zamir wrote: > > Hi, > > > I have encountered a problem in using SSL sockets in blocking mode. My > > application is multi threaded, with one thread waiting to read and > > another that is waiting to write. Upon some external input, a third > > thread tries to shutdown the connection and then close the socket. > > However, calling PR_Shutdown or PR_Close never returns from > > SSL_LOCK_READER(ss). > > Calling PR_Close then is a programming error. While one thread > is blocking in PR_Recv, another thread cannot call PR_Close on > that socket because PR_Close will free the PRFileDesc structure > representing that socket. That is, one thread should not free > the memory still in use by another thread. I believe the > SSL_LOCK_READER(ss) macros are intended to detect or prevent > such programming errors from crashing NSS. > > Off the top of my head, I don't know why we can't call > PR_Shutdown while another thread is blocking in PR_Recv. > The presence of the SSL_LOCK_READER(ss) macro in > ssl_Shutdown (http://lxr.mozilla.org/mozilla1.8/ident?i=ssl_Shutdown) > shows it is also considered a programming error. I just > don't know why. > > Wan-Teh
Yes, clearly PR_Shutdown was written to block until the lock is available... So I would like to rephrase my question -- when an NSPR socket is blocking on Read or Write, what is the way to move the socket out of that state (avoiding the workaround of using timeout for that purpose), in order to close it? _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
