[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