I did not test the trunk yet.

I poked around the code a bit, and this is what I believe happens: lightning's (SSL) socket is polled on read | write. I see that in nsSSLThread.cpp requestPoll(), the socket currently serviced by the thread is the IMAPS socket, so the switch on si->mThreadData->mSSLState gets evaluated. We hit ssl_idle. The problem is that si->mThreadData->mOneBytePendingFromEarlierWrite is true, so the poll returns immediately claiming that the lightning socket has something to work on, and resetting all other sockets' poll status.

The poll result "write" is now handled by trying to write to the Lightning SSL socket. That fails, though, because the IMAPS socket is blocking the SSL thread. Here is the relevant backtrace of the failure:

>	pipnss.dll!nsSSLThread::requestWrite(nsNSSSocketInfo * si=0x04a66e68, const void * buf=0x04e7c9b5, int amount=323)  Line 734	C++
 	pipnss.dll!nsSSLIOLayerWrite(PRFileDesc * fd=0x03d6fa90, const void * buf=0x04e7c9b5, int amount=323)  Line 1351 + 0x11 bytes	C++
 	nspr4.dll!PR_Write(PRFileDesc * fd=0x03d6fa90, const void * buf=0x04e7c9b5, int amount=323)  Line 146 + 0x14 bytes	C
 	necko.dll!nsSocketOutputStream::Write(const char * buf=0x04e7c9b5, unsigned int count=323, unsigned int * countWritten=0x022dfe0c)  Line 550 + 0x12 bytes	C++
 	necko.dll!nsHttpConnection::OnReadSegment(const char * buf=0x04e7c9b5, unsigned int count=323, unsigned int * countRead=0x022dfe0c)  Line 524 + 0x26 bytes	C++
 	necko.dll!nsHttpTransaction::ReadRequestSegment(nsIInputStream * stream=0x046e0b80, void * closure=0x049cee60, const char * buf=0x04e7c9b5, unsigned int offset=0, unsigned int count=323, unsigned int * countRead=0x022dfe0c)  Line 405 + 0x1c bytes	C++
 	xpcom_core.dll!nsMultiplexInputStream::ReadSegCb(nsIInputStream * aIn=0x04c554c8, void * aClosure=0x022dfe10, const char * aFromRawSegment=0x04e7c9b5, unsigned int aToOffset=0, unsigned int aCount=323, unsigned int * aWriteCount=0x022dfe0c)  Line 288 + 0x29 bytes	C++
 	xpcom_core.dll!nsStringInputStream::ReadSegments(unsigned int (nsIInputStream *, void *, const char *, unsigned int, unsigned int, unsigned int *)* writer=0x002ff4f0, void * closure=0x022dfe10, unsigned int aCount=323, unsigned int * result=0x022dfe0c)  Line 240 + 0x22 bytes	C++
 	xpcom_core.dll!nsMultiplexInputStream::ReadSegments(unsigned int (nsIInputStream *, void *, const char *, unsigned int, unsigned int, unsigned int *)* aWriter=0x02023ee0, void * aClosure=0x049cee60, unsigned int aCount=4096, unsigned int * _retval=0x022dfea4)  Line 245 + 0x28 bytes	C++
 	necko.dll!nsHttpTransaction::ReadSegments(nsAHttpSegmentReader * reader=0x049f1670, unsigned int count=4096, unsigned int * countRead=0x022dfea4)  Line 430 + 0x2b bytes	C++
 	necko.dll!nsHttpConnection::OnSocketWritable()  Line 559 + 0x1e bytes	C++
 	necko.dll!nsHttpConnection::OnOutputStreamReady(nsIAsyncOutputStream * out=0x049f1900)  Line 770 + 0xb bytes	C++
 	necko.dll!nsSocketOutputStream::OnSocketReady(unsigned int condition=0)  Line 490	C++
 	necko.dll!nsSocketTransport::OnSocketReady(PRFileDesc * fd=0x03d6fa90, short outFlags=2)  Line 1474	C++

Writing returns with an error code due to this piece of code (the line numbers in above backtrace are +/- a few due to my debug output, so I'm posting it here):

        if (some_other_socket_is_busy)
        {
          PORT_SetError(PR_WOULD_BLOCK_ERROR);
          return -1;


That keeps my CPU pretty busy: mOneBytePendingFromEarlierWrite is constantly true, and so the Lightning socket constantly tries to write and constantly fails.

I did not manage to identify the IMAPS socket in the list of sockets to poll. Do you have a hint where mOneBytePendingFromEarlierWrite should get reset, and why it might stay true without the IMAPS socket owner caring?

I see that two threads are communicating with the IMAP server, both are in nsPipeInputStream::Wait(). One wants to know the quota of the INBOX, the other wants to know the capabilities. The stack traces I posted earlier only show the latter (see ParseIMAPandCheckForNewMail() which issues "1 capability"), so the other connection is probably not significant.

[Sorry for the lengthy post, but it's a pretty complex context and I don't know the code well enough to be able to judge what's obvious and what isn't.]