| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This would otherwise shadow the poll_ready method, which is
confusing.
Also this paves the way for making it available for any
Sink + Unpin.
Improve the docs somewhat to explain what this thing actually is.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I think this error was in fact always Error::CircuitClosed because it
came from ChannelClosed.into(). Anyway, we shouldn't squash it.
Now this function has semantics identical to Sink::poll_ready, just a
slightly different signature.
|
| | | |
| | |
| | |
| | | |
Make it clear we're discarding `()`, not an actual value.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We're going to change this function, but first we are going to make
its behaviour identical to Sink::poll_ready.
This avoids open-coding the call to poll_read on cell_tx.
The error handling is still strange. We'll fix that in a moment.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
proto: Make DataWriter::close actually do something.
Closes #1368
See merge request tpo/core/arti!2170
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This test verifies that when we invoke the code to close a stream,
an END message is actually sent.
The test comes in two versions:
* `drop_stream` closes the stream by dropping it. It currently
passes on main.
* `close_stream` closes the stream by running `AsyncWriteExt::close`
on the writer. It is a regression test for #1368. It currently
fails on main.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In particular, clarify that dropping the DataWriter on its own does
nothing unless the DataReader is also dropped.
Related to #1368.
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously we had a bug where `<DataWriter as AsyncWrite>::close`
(or `shutdown` in tokio-land) would not actually have any effect.
It _would_ drop the `StreamTarget` held by the `DataWriter`, but
since the `DataReader` also held a `StreamTarget`, the
MPSC channel would not get closed, and the circuit reactor would
not realize that the stream wanted to shut down.
Now we use `mpsc::Sender::close_channel` to make our closes
effectual.
Closes #1368.
Additionally, we fix a bug where `poll_close()` never actually did
anything if the buffer had nothing in it when it was called.
Previously, `poll_flush_impl()` would exit immediately if it had no
data to flush. That isn't what we want when we are closing!
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
mypy: Enable strict mode
See merge request tpo/core/arti!2169
|
| | | |
| | |
| | |
| | |
| | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2169#note_3033481
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Consultation with a nearby Python expert, on another topic, revealed
that without --strict, mypy turns most of its stuff off by default.
Sadly (?) this bureaucracy didn't find any bugs.
|
| | | | |
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | | |
Proto: Refactor Channel to always be Arc.
See merge request tpo/core/arti!2163
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously ChannelDetails had a double duty: It held elements shared
among the clones of a Channel, and it also held elements shared
between the Channel and the Reactor. But now that Channel doesn't
have to implement Clone, we can more the non-Reactor elements into
Channel itself.
This change may improve cache locality a bit, and should make it a
little easier to follow the channel code.
I've also moved unique_id out of ChannelDetails into Channel _and_
Reactor: it is small, immutable, and used all the time in logging.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously, Channel was a type that you could Clone that implicitly
its state. Now, Channel always appears as an Arc<Channel>.
This change has several benefits:
* It makes the relationship between Channel struct and the
underlying channel more clear.
* It enables Channel to participate in the RPC system,
where everything has to be an Arc<.>
* It enables us to have a Weak<Channel>, if we ever want to.
* It will let us move various members out of ChannelDetails.
We did this change a while ago with ClientCirc.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This serves three purposes:
* It removes the 'send a cell' method from the channel's public
API. Nothing outside of tor-proto should have to use this.
* It paves the way for giving each circuit a separate handle onto
the channel's send functionality. This will eventually let
the channel multiplex among circuits more intelligently.
* It prepares for the next commit, which will make Channel itself
universally Arc<.>ed.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
For all mutable shared state, we ought to know which part of the
program sets it, which part of the program reads it, and why.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
chanmgr: Delegate to Channel::engage_padding_activities explicitly.
See merge request tpo/core/arti!2164
|
| |/ / /
| | |
| | |
| | |
| | |
| | | |
(This isn't a bugfix, but it helps avoid the appearance of a
function calling itself. This _would_ become a bug if we imported
the wrong trait into scope here.)
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Downgrade Cargo.lock to previous libc crate version
See merge request tpo/core/arti!2166
|
| |/ / /
| | |
| | |
| | | |
The current version has been yanked.
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
Add two blank lines to CHANGELOG.
See merge request tpo/core/arti!2165
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | | |
CI: Move cargo clean section to after_script.
See merge request tpo/core/arti!2159
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Part of arti#1410.
The idea here is to consolidate `cargo clean` in an after_script
section we call everywhere, rather than have it be in one that we
can forget to copy.
We can't call `cargo clean` unconditionally, though, since some of
our jobs don't install cargo. So we make sure it's there.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Allow RPC methods with non-serializable types
Closes #1403
See merge request tpo/core/arti!2152
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
We need to do this so that we can actually invoke RPC functions
from one another.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Now that Method::Error exists, we can downcast Any to the actual
function's return type.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is needed so that we can cast special methods' return types
properly.
I wish I could make this optional, but Rust doesn't allow
defaulting an associated type.
|
| | | | |
| | | |
| | | |
| | | | |
A @special invoker does not get an RPC entry.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Now Methods can return anything; and only if their outputs are
Serialize will they implement RpcInvocable.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
RpcInvocable will only be implemented on types whose output
can be serialized.
|
| | | | |
| | | |
| | | |
| | | | |
This is part of work on #1403.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This will allow us to create dispatchable methods that are only
invoked from inside the arti code, and are not themselves
serializable.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Provide and run script for making/checking link blocks in CHANGELOG.md
Closes #1388
See merge request tpo/core/arti!2126
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2126#note_3030954
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Suggested here
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2126#note_3026423
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|