thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ephraim Dan <E....@F5.com>
Subject RE: TSocket::peek() - shouldn't it be non-blocking?
Date Mon, 20 Jul 2009 13:14:23 GMT
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:E.Dan@F5.com] 
Sent: Monday, July 20, 2009 15:06
To: thrift-user@incubator.apache.org
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

Mime
View raw message