Background:
I've developed a C++ RPC server using protobufs as the IDL. It works
great. Thanks for protobufs!
Problem:
When a client connects to the RPC server, a seperate thread in the
server handles the connection and blocks, waiting for data from the
client.
My message parsing function for
On Sep 28, 2010, at 15:33 , Patrick wrote:
This is all fine and dandy except when I want to shutdown the server
or connection (not client initiated). The ReadTag (as well as the
other Read functions) blocks until data is received but I want it to
timeout after a specified amount of time. So in
They'll probably be around forever. But internally we have changed the
default of *_generic_services to false. I'm not sure yet if we want to do
the same thing in the public release -- internally, we were able to actually
update every piece of code that was affected, but obviously we have no
Thanks Evan. I don't really want to buy the cow to get a glass of
milk.
I also have the problem that the RPC I wrote comes in a threaded model
and a multi-process model. The multi-process one makes some things a
bit harder. I was hoping to utilize a shm mutex to signal termination
but this would
Thanks Evan. I don't really want to buy the cow to get a glass of
milk.
I also have the problem that the RPC I wrote comes in a threaded
model
and a multi-process model. The multi-process one makes some things a
bit harder. I was hoping to utilize a shm mutex to signal termination
but this would
Not sure who Ken is, but I don't have much to add here. The protobuf
parsing code is not designed for non-blocking I/O (which would be
excessively complicated). If you need non-blocking I/O, the only thing you
can do is read to a separate buffer, and only invoke the protobuf parser
when you've
On Sep 28, 2010, at 18:36 , Patrick wrote:
I also have the problem that the RPC I wrote comes in a threaded model
and a multi-process model. The multi-process one makes some things a
bit harder. I was hoping to utilize a shm mutex to signal termination
but this would only work if my message
On Tue, Sep 28, 2010 at 5:38 PM, Evan Jones ev...@mit.edu wrote:
On Sep 28, 2010, at 18:36 , Patrick wrote:
I also have the problem that the RPC I wrote comes in a threaded model
and a multi-process model. The multi-process one makes some things a
bit harder. I was hoping to utilize a shm
On Sep 28, 6:07 pm, Kenton Varda ken...@google.com wrote:
On Tue, Sep 28, 2010 at 5:38 PM, Evan Jones ev...@mit.edu wrote:
On Sep 28, 2010, at 18:36 , Patrick wrote:
I also have the problem that the RPC I wrote comes in a threaded model
and a multi-process model. The multi-process one
