[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [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:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  rust-pilot, rust, datatypes,         |  Actual Points:
  034-triage-20180328, 034-removed-20180328      |
Parent ID:                                       |         Points:  3
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor8-can
-------------------------------------------------+-------------------------

Comment (by nickm):

 Replying to [comment:8 cypherpunks]:
 > Since
 [https://gitweb.torproject.org/tor.git/commit/?id=d8b34e0886c9fd08fb51e0de4fadca7da82056ff
 d8b34e0886c9fd08fb51e0de4fadca7da82056ff], buffers.c has been split and
 refactored four ways now, so there are three callers in the C code that
 still dig into the implementation detail guts of `buf_t` in search of raw
 pointers, presumably with the benefit of zero-copy performance.
 >
 > Could `compress_buf.c`, `buffers_net.c`, and `buffers_tls.c` just switch
 to using the single-copy public API, or should a new zero-copy API be
 added that the Rust version can implement too?

 So, I'd be fine with either one of these as a separate patch.  Rather than
 needing a callback, I'd prefer an approach that exposed the contents of
 the underlying buf_t as something iovec-like.

 The reason I'd be okay with either approach for now is that in any
 reasonable implementation of memcpy, copying data is far cheaper than TLS
 or compression, and we don't need to worry about an extra copy too much.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23878#comment:9>
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