You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@thrift.apache.org by Ephraim Dan <E....@F5.com> on 2009/07/20 14:05:47 UTC
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
Re: TSocket::peek() - shouldn't it be non-blocking?
Posted by David Richards <dr...@showcase60.com>.
unsubscribe
On Jul 20, 2009, at 6:05 AM, Ephraim Dan wrote:
> 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
Re: TSocket::peek() - shouldn't it be non-blocking?
Posted by Bruce Simpson <bm...@incunabulum.net>.
Ephraim Dan wrote:
> Hm...
> I will look into it.
> Is there a way to bypass the BufferedTransport layer and just use the socket directly to pass the structs? That way I could just set it to non-blocking myself and I think I'd be good to go.
>
David Reiss posted an example here of how to use TMemoryBuffer to do
this, in response to my initial question, last month. See thread
'Non-blocking C++ client?' in the archives.
thanks,
BMS
RE: TSocket::peek() - shouldn't it be non-blocking?
Posted by Ephraim Dan <E....@F5.com>.
Hm...
I will look into it.
Is there a way to bypass the BufferedTransport layer and just use the socket directly to pass the structs? That way I could just set it to non-blocking myself and I think I'd be good to go.
Thanks
-----Original Message-----
From: Rush Manbert [mailto:rush@manbert.com]
Sent: Tuesday, July 21, 2009 19:58
To: thrift-user@incubator.apache.org
Subject: Re: TSocket::peek() - shouldn't it be non-blocking?
I'm afraid not. What I implemented exactly mimics the behavior of the
existing Thrift socket code.
Sorry I can't help, but a patch for async client side operation was
posted to the developer list. You might search there. The title was:
"Asynchronous C++ client/server (THRIFT-1)"
- Rush
On Jul 21, 2009, at 9:32 AM, Ephraim Dan wrote:
> I am looking for a client-side solution. But we're not using the
> rpc layer layer here - just transport and protocol for raw structs
> over a socket.
>
> Is your solution going to help me?
>
> Thanks.
>
> -----Original Message-----
> From: Rush Manbert [mailto:rush@manbert.com]
> Sent: Tuesday, July 21, 2009 19:03
> To: thrift-user@incubator.apache.org
> Subject: Re: TSocket::peek() - shouldn't it be non-blocking?
>
>
> On Jul 20, 2009, at 10:18 PM, Ephraim Dan wrote:
>
>> That explains it.
>>
>> Is there a way to get the behavior I want, i.e. to check before
>> reading in order not to block? Is there a non-blocking transport
>> layer or do the existing ones support nonblocking sockets?
>
> If we're talking about the server side, there is TNonblockingServer
> (and I will be adding TAsioNonblockingServer), but I believe all the
> transports call TSocket::read() when you do a peek at a higher level.
> I haven't seen anyone call TSocket::peek in the code that I've read.
>
> - Rush
Re: TSocket::peek() - shouldn't it be non-blocking?
Posted by Rush Manbert <ru...@manbert.com>.
I'm afraid not. What I implemented exactly mimics the behavior of the
existing Thrift socket code.
Sorry I can't help, but a patch for async client side operation was
posted to the developer list. You might search there. The title was:
"Asynchronous C++ client/server (THRIFT-1)"
- Rush
On Jul 21, 2009, at 9:32 AM, Ephraim Dan wrote:
> I am looking for a client-side solution. But we're not using the
> rpc layer layer here - just transport and protocol for raw structs
> over a socket.
>
> Is your solution going to help me?
>
> Thanks.
>
> -----Original Message-----
> From: Rush Manbert [mailto:rush@manbert.com]
> Sent: Tuesday, July 21, 2009 19:03
> To: thrift-user@incubator.apache.org
> Subject: Re: TSocket::peek() - shouldn't it be non-blocking?
>
>
> On Jul 20, 2009, at 10:18 PM, Ephraim Dan wrote:
>
>> That explains it.
>>
>> Is there a way to get the behavior I want, i.e. to check before
>> reading in order not to block? Is there a non-blocking transport
>> layer or do the existing ones support nonblocking sockets?
>
> If we're talking about the server side, there is TNonblockingServer
> (and I will be adding TAsioNonblockingServer), but I believe all the
> transports call TSocket::read() when you do a peek at a higher level.
> I haven't seen anyone call TSocket::peek in the code that I've read.
>
> - Rush
RE: TSocket::peek() - shouldn't it be non-blocking?
Posted by Ephraim Dan <E....@F5.com>.
I am looking for a client-side solution. But we're not using the rpc layer layer here - just transport and protocol for raw structs over a socket.
Is your solution going to help me?
Thanks.
-----Original Message-----
From: Rush Manbert [mailto:rush@manbert.com]
Sent: Tuesday, July 21, 2009 19:03
To: thrift-user@incubator.apache.org
Subject: Re: TSocket::peek() - shouldn't it be non-blocking?
On Jul 20, 2009, at 10:18 PM, Ephraim Dan wrote:
> That explains it.
>
> Is there a way to get the behavior I want, i.e. to check before
> reading in order not to block? Is there a non-blocking transport
> layer or do the existing ones support nonblocking sockets?
If we're talking about the server side, there is TNonblockingServer
(and I will be adding TAsioNonblockingServer), but I believe all the
transports call TSocket::read() when you do a peek at a higher level.
I haven't seen anyone call TSocket::peek in the code that I've read.
- Rush
Re: TSocket::peek() - shouldn't it be non-blocking?
Posted by Rush Manbert <ru...@manbert.com>.
On Jul 20, 2009, at 10:18 PM, Ephraim Dan wrote:
> That explains it.
>
> Is there a way to get the behavior I want, i.e. to check before
> reading in order not to block? Is there a non-blocking transport
> layer or do the existing ones support nonblocking sockets?
If we're talking about the server side, there is TNonblockingServer
(and I will be adding TAsioNonblockingServer), but I believe all the
transports call TSocket::read() when you do a peek at a higher level.
I haven't seen anyone call TSocket::peek in the code that I've read.
- Rush
Re: TSocket::peek() - shouldn't it be non-blocking?
Posted by Rush Manbert <ru...@manbert.com>.
On Jul 21, 2009, at 6:54 AM, Ephraim Dan wrote:
> OK - is there a ticket or something I can follow for updates?
Please see: https://issues.apache.org/jira/browse/THRIFT-311
I've put a couple of status updates there in response to a "what's
going on?" question posted to the developer list.
>
> -----Original Message-----
> From: Bruce Simpson [mailto:bms@incunabulum.net]
> Sent: Tuesday, July 21, 2009 16:31
> To: thrift-user@incubator.apache.org
> Subject: Re: TSocket::peek() - shouldn't it be non-blocking?
>
> Ephraim Dan wrote:
>> That explains it.
>>
>> Is there a way to get the behavior I want, i.e. to check before
>> reading in order not to block? Is there a non-blocking transport
>> layer or do the existing ones support nonblocking sockets?
>>
>
> I've been testing Rush Manbert's on Linux and BSD UNIX which is in
> development at the moment.
>
> He will be submitting it to the Thrift maintainers soon.
But it won't implement nonblocking client sockets. There's a separate
effort underway for that. Nonblocking server is already available.
- Rush
RE: TSocket::peek() - shouldn't it be non-blocking?
Posted by Ephraim Dan <E....@F5.com>.
OK - is there a ticket or something I can follow for updates?
-----Original Message-----
From: Bruce Simpson [mailto:bms@incunabulum.net]
Sent: Tuesday, July 21, 2009 16:31
To: thrift-user@incubator.apache.org
Subject: Re: TSocket::peek() - shouldn't it be non-blocking?
Ephraim Dan wrote:
> That explains it.
>
> Is there a way to get the behavior I want, i.e. to check before reading in order not to block? Is there a non-blocking transport layer or do the existing ones support nonblocking sockets?
>
I've been testing Rush Manbert's on Linux and BSD UNIX which is in
development at the moment.
He will be submitting it to the Thrift maintainers soon.
Re: TSocket::peek() - shouldn't it be non-blocking?
Posted by Bruce Simpson <bm...@incunabulum.net>.
Ephraim Dan wrote:
> That explains it.
>
> Is there a way to get the behavior I want, i.e. to check before reading in order not to block? Is there a non-blocking transport layer or do the existing ones support nonblocking sockets?
>
I've been testing Rush Manbert's on Linux and BSD UNIX which is in
development at the moment.
He will be submitting it to the Thrift maintainers soon.
RE: TSocket::peek() - shouldn't it be non-blocking?
Posted by Ephraim Dan <E....@F5.com>.
That explains it.
Is there a way to get the behavior I want, i.e. to check before reading in order not to block? Is there a non-blocking transport layer or do the existing ones support nonblocking sockets?
-----Original Message-----
From: David Reiss [mailto:dreiss@facebook.com]
Sent: Monday, July 20, 2009 20:32
To: thrift-user@incubator.apache.org
Subject: Re: TSocket::peek() - shouldn't it be non-blocking?
> 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?
No. It's a way for the processor to determine if the socket has been closed
before trying to read another request (and complaining that it is incomplete).
It is not supposed to be nonblocking.
Re: TSocket::peek() - shouldn't it be non-blocking?
Posted by David Reiss <dr...@facebook.com>.
> 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?
No. It's a way for the processor to determine if the socket has been closed
before trying to read another request (and complaining that it is incomplete).
It is not supposed to be nonblocking.
RE: TSocket::peek() - shouldn't it be non-blocking?
Posted by Ephraim Dan <E....@F5.com>.
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