[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #23878 [Core Tor/Tor]: Attempt rewriting buffers.c in Rust
#23878: Attempt rewriting buffers.c in Rust
------------------------------+-----------------------------------------
Reporter: isis | Owner: (none)
Type: enhancement | Status: new
Priority: Medium | Milestone: Tor: 0.3.4.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Keywords: rust-pilot, rust, datatypes
Actual Points: | Parent ID:
Points: 3 | Reviewer:
Sponsor: Sponsor8-can |
------------------------------+-----------------------------------------
In buffers.c, we define `buf_t`, which is essentially a doubly-linked list
comprised of chunks of contiguously-allocated memory. During the Montréal
meeting, we identified `buf_t` as a potentially good candidate datatype
for reimplementation in Rust.
My understanding of possibly the ideal way to do this (after talking with
Alex Crichton, without boats, nickm, and Nika Layzell) would be to
entirely rethink the implementation in terms of a `VecDeque<Bytes>` using
[https://doc.rust-lang.org/nightly/std/collections/struct.VecDeque.html
VecDeque from the stdlib] and [https://carllerche.github.io/bytes/bytes/
Bytes or another buffer type from the bytes crate]. If this is something
which works out, we could then (hopefully!) expose a similar API as to the
C interface. (If that doesn't work out, there's only a couple points in
the code which appear to rely on the current implementation of `buf_t`.)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23878>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs