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:[email protected]] Sent: Tuesday, July 21, 2009 19:58 To: [email protected] 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:[email protected]] > Sent: Tuesday, July 21, 2009 19:03 > To: [email protected] > 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
