First, a quick note about the non-blocking server. It uses nonblocking I/O, but the actual application callback is called synchronously (either in the main thread or in a worker thread), so it has to be synchronous (put another way, the return value for the RPC must be built before the handler function returns).
There is currently no explicit support for doing non-blocking RPC in Thrift (at least from C++. I'm not sure how the Twisted stuff works). Someone at Facebook is working on support for this, and we should be able to release it soonish. In the mean time, one thing you can do is send your message to a TMemoryBuffer, transport that to the backend using whatever system you want, then receive the result from another TMemoryBuffer. For example, if you have a function called "foo": shared_ptr<TMemoryBuffer> buf(new TMemoryBuffer); shared_ptr<MyClient> cl(new MyClient(shared_ptr<TProtocol>(new TBinaryProtocol(buf))); cl->send_foo(args); uint8_t* bytes; uint32_t nbytes; buf->getBuffer(&bytes, &nbytes); // stash buf and cl somewhere. // ship nbytes of bytes off to the server // get the server's response buf->resetBuffer(response, response_len); int ret = cl->recv_foo(); --David Bruce Simpson wrote: > Hi all, > > I am currently evaluating Thrift with a view to replacing the XRL IPC > mechanism in XORP, http://www.xorp.org/. > > XORP is the only actively developed open source solution for Internet > multicast routing in the industry. Having said that, PIM is quite a > complex protocol, and in XORP, everything is realized in C++. > > One consequence of how XORP has been developed is that all XORP > processes are single threaded. An existing slim class library implements > the common idioms of the Reactor pattern, EventLoop, etc. All XRL calls > are asynchronous, and require the use of event-driven callbacks. > > I notice that the C++ client examples for Thrift either assume it's O.K. > to use threads, or use blocking I/O. Can anyone point me at an example > of how to do non-blocking RPC in C++ with Thrift? If not, roughly how > much work is it going to be to add? > I see that non-blocking servers are just fine -- and that there are some > patches floating around to improve that too. > > I am excited by Thrift's possibilities, however, need to ensure that it > can fit into our framework O.K. > > thanks very much, > BMS > > P.S. I am also very interested in Thrift + AMQP in a non-blocking C++ > context, the clustering and virtualization case is strong.
