Comments (5)
serialize::new_reader()
and MallocMessageBuilder
are of course not what you want because they do allocations and must copy the underlying data.
On the reading side, you could manually read the segment table, construct a &[&[Word]]
from the body of the message, and use that to make a SegmentArrayMessageReader
. This is currently more cumbersome than it ought to be. We should have a FlatArrayMessageReader
that takes care of this stuff.
The writing side is more problematic. I think that as things currently stand you actually cannot avoid copying the data. I had hoped that ScratchSpaceMallocMessageBuilder
might be able to help, but unfortunately for our purposes here it zeroes the scratch space when it is dropped. To move forward on this front, I think we need a way to allow user-defined implementations of MessageBuilder
to specify their own allocation schemes, as with the MessageBuilder.allocateSegment()
virtual method in capnproto-c++.
from capnproto-rust.
Maybe instead of using a &[&[Word]] you could use a *const u64 and use pointer offsets.
This way you wouldn't have to create slices from raw pointers - and worry about their lifetimes.
Wrt the segment table, I see it partially defined like this:
(N * 4 bytes) The size of each segment, in words.
4 bytes per word = 32-bit word size. Rust defines it (incorrectly/incompatibly?) as u64:
pub struct Word {_unused_member : u64}
Part of the reason for using Capn'Proto is because it advertises zero-cost [de]serialization. I assume in C++ that I:
- create a builder that points to a mmap region
- set_x(), set_y(), ...
- I'm done writing, because the set_x() etc. methods have directly written to the mmap region.
- another process simply creates a reader that points to the mmap region and it's done; it can call get_x().
If my understanding is correct, is it the goal of capnproto-rust to get to this point?
- zero allocations, zero copies, no serialize::[new_reader,write_message] required?
Thanks!
(and thanks for all the great work so far)
from capnproto-rust.
Maybe instead of using a &[&[Word]] you could use a *const u64 and use pointer offsets.
This way you wouldn't have to create slices from raw pointers - and worry about their lifetimes.
I don't think it should be the library's job to do this conversion. How would it know what lifetimes to use?
Wrt the segment table, I see it partially defined like this:
(N * 4 bytes) The size of each segment, in words.
Maybe this would be more clear if it said "(N * 4 bytes) For each segment, an unsigned 32-bit integer representing the number of words in that segment."
If my understanding is correct, is it the goal of capnproto-rust to get to this point?
zero allocations, zero copies, no serialize::[new_reader,write_message] required?
Yes, we should be able to support such things. Perhaps you'd be interested in contributing to this? :)
from capnproto-rust.
I think it would be fun to work on this.
Currently swamped. Will circle back shortly.
from capnproto-rust.
Note that @ArtemGr has made some progress on this front: #25
from capnproto-rust.
Related Issues (20)
- Primitive list panicks if the list type is `Void` HOT 1
- Null values for non active union members HOT 3
- Switch Allocator to act more like an owned arena HOT 8
- Reader fails with out of bounds pointer error when reading from compressed stream HOT 1
- Revert text setter ergonomics pessification; add raw_set methods HOT 6
- calculator example fails with java server: Cannot read capability pointer without capTable HOT 1
- c++.capnp compiles to unusable module name HOT 6
- How to send generated readers across threads HOT 3
- From bytes to TypedReader HOT 6
- Allowing construction of NoAllocSliceSegments with buffer and NoAllocBufferSegmentType HOT 7
- Kudos to builders of this Rust library - Every single one of you. HOT 3
- [Question]How to extract generic type values HOT 5
- capnp_rpc does not work on monoio HOT 4
- Dynamic parsing of fields may panic HOT 1
- traits.ListIter incorrectly implementing ExactSizeIterator HOT 1
- oc
- Using same schema file for both Rust and C++ HOT 1
- doc: read_message_from_flat_slice_no_alloc docstring bad autocomplete HOT 1
- Making rust capn proto fully async HOT 2
- Is there any reason why Rc<RefCell> is used compared to Arc<Mutex>?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from capnproto-rust.