Sorry - looks like I had a misunderstanding - I think what's blocking is the TBufferedTransport::peek() code:
setReadBuffer(rBuf_.get(), transport_->read(rBuf_.get(), rBufSize_)); I still don't understand why it's not calling TSocket::peek() (didn't quite follow the THRIFT-96 discussion) but in any case it seems like TSocket::peek() would block anyway, as I noted below. So I'm still left with the question - isn't peek() supposed to be a nonblocking way to check if a read would block? If so, why isn't it working for me, and if not, how do I get that behavior? Thanks -----Original Message----- From: Ephraim Dan [mailto:[email protected]] Sent: Monday, July 20, 2009 15:06 To: [email protected] Subject: TSocket::peek() - shouldn't it be non-blocking? Hi - I am trying to use TBufferedTransport::peek() to find out if an attempt to read a message would block. >From what I understand from the code, TBufferedTransport will delegate the >call to TSocket given that I'm using that as the underlying transport. My problem is that TSocket::peek() appears to block! I think the offending code is: int r = recv(socket_, &buf, 1, MSG_PEEK); Seems like it shouldn't block, that being the point of peek(), and should read: int r = recv(socket_, &buf, 1, MSG_PEEK | MSG_DONTWAIT); Am I missing something? Is there some way to get this working the way I'm expecting and hoping that it will work? Thanks
