Persisting RPC Arguments

[Matthew Maurer]

Is there a way to explicitly take ownership of a ::Reader object acquired from the argument to an RPC call so that it is not freed when I finish servicing it?

It makes sense for the framework to throw the data away by default, but in my case I literally want to keep the value to read through in a later rpc call.

The only way I can really see around this is to define a type structure that mirrors my capnp file and translate between the two, which seems against the zero copy spirit of how this is supposed to work.

--Matthew Maurer

[Matthew Maurer]

To be specific, I don't see anything like "disownParams", so I can't adopt them, I can only set them.

[Kenton Varda]

Hi Matthew,

At present the only thing you can do is copy the params into a new MessageBuilder. Copying should be pretty fast (certainly far faster than a protobuf decode).

We could perhaps add something like a disownParams() method. But this could be tricky with certain transport implementations. Memory management is the transport's job, and it's expected that future transports may care deeply about exactly where messages are allocated and when they are freed. For example, a shared-memory transport may have a limited amount of shared memory to use for transmitting messages. If you don't free the message, you may actually be preventing further RPCs from being transmitted, while they wait for space to become available. Similarly you could imagine a transport implementation that is tied to specialized network hardware that copies messages directly into memory from the wire, but only has a limited amount of space for doing this.

I'd advise making a copy for now, and take some profiles to see how much this actually hurts performance. If it is a problem, we can discuss the possibility of adding disownParams() and figure out how to deal with the caveats.

-Kenton

--

Sandstorm.io is crowdfunding! http://igg.me/at/sandstorm

--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+...@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.

[Andrew Lutomirski]

On Fri, Aug 15, 2014 at 11:43 AM, Kenton Varda <ken...@sandstorm.io> wrote:
> Hi Matthew,
>
> At present the only thing you can do is copy the params into a new
> MessageBuilder. Copying should be pretty fast (certainly far faster than a
> protobuf decode).
>
> We could perhaps add something like a disownParams() method. But this could
> be tricky with certain transport implementations. Memory management is the
> transport's job, and it's expected that future transports may care deeply
> about exactly where messages are allocated and when they are freed. For
> example, a shared-memory transport may have a limited amount of shared
> memory to use for transmitting messages. If you don't free the message, you
> may actually be preventing further RPCs from being transmitted, while they
> wait for space to become available. Similarly you could imagine a transport
> implementation that is tied to specialized network hardware that copies
> messages directly into memory from the wire, but only has a limited amount
> of space for doing this.
>
> I'd advise making a copy for now, and take some profiles to see how much
> this actually hurts performance. If it is a problem, we can discuss the
> possibility of adding disownParams() and figure out how to deal with the
> caveats.

One solution: add disownOrCopyParams() instead.

I suspect that implementing disown might be somewhat nasty on Windows
or, more generally, on any platform that uses a proactor model. It
might be completely impossible without dangerous overhead or other
caveats on some fancy zero-copy architectures (OpenOnload's low-level
API, for example).

--Andy

[Matthew Maurer]

It is not an actual performance problem, I was just trying to write things The Right Way the first time. I'm just using a fresh MallocMessageBuilder and .setRoot (which I hope is the right way to do this) for now.

[Kenton Varda]

On Fri, Aug 15, 2014 at 12:24 PM, Matthew Maurer <mau...@matthewmaurer.org> wrote:

It is not an actual performance problem, I was just trying to write things The Right Way the first time. I'm just using a fresh MallocMessageBuilder and .setRoot (which I hope is the right way to do this) for now.

Yep, that's the right thing to do.

-Kenton