| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Since we renamed PollingStream and NonblockingStream to
BlockingConnection and NonblockingConnection, it no longer makes
sense to refer to them as streams, or put them in variables called
"stream".
|
| |
|
|
|
| |
Since we are no longer calling these types "streams" I've decided to
revert to the old name for this module.
|
| | |
|
| | |
|
| |
|
|
| |
Typos found with codespell
|
| |
|
|
|
| |
This commit adds FFI wrappers for the "poll" API, which lets the
user integrate with a poll(2)-style event loop.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Per discussion, it makes more sense to have the API be one
that gets called when our IO interests change.
Additionally, this commit removes the try_reading and try_writing
booleans, as previously discussed.
I've left a couple of XXXX comments where more documentation or
thought is likely needed.
|
| |
|
|
|
|
|
| |
This API provides the necessary functionality to use an RpcConn
inside a poll-like event loop.
This is part of #1856.
|
| | |
|
| |
|
| |
(from Diziet)
|
| | |
|
| |
|
|
| |
This is based on a pad with input from nickm and Diziet
|
| |
|
|
|
|
|
|
|
|
|
| |
This commit finally adds a `RpcConn::submit()` method to send a
request without having to wait on it specifically, and an
`RpcConn::wait()` method to wait for the next response from _any_
such request.
Thanks to the previous patches, this is relatively simple!
This is part of #1856.
|
| |
|
|
|
|
| |
In order to implement tagged pollable requests, we need a separate
response queue for them, and we need to dispatch requests to that
queue as appropriate.
|
| |
|
|
|
|
|
| |
For pollable requests, we'll want to associate each one with a tag.
But we'd rather not carry tags around for _every_ pending request:
it would waste space and lead to possible errors. So instead we
add a Tag type as a member of QueueId.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to implement this part of #1856, we will internally divide
requests into two kinds: "Waitable" and "Pollable". Waitable
requests are the kind that we have now: They are created with an
"execute" method. They each have their own response queue and their
own condvar, and in order to see if they have any responses, the
caller needs to call some kind of request-specific method.
Pollable requests are the ones we will add. They are created with a
"submit" method, and associated with a user-provided tag.
They all share the same queue and the same condvar.
To see if any of them have a response, the caller will run a
function that returns tagged responses.
In order to support this division, this commit:
- turns `RequestState` into an enum,
- makes `ResponseQueue` into its own type,
- Adds a trait that will be implemented by every type that can
identify a response queue.
|
| | |
|
| |
|
|
| |
All the tests still pass!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Example:
```text
warning: doc list item overindented
--> crates/arti-rpc-client-core/src/conn/connimpl.rs:322:9
|
322 | /// indicates that no more messages will be received for this request.
| ^^^ help: try using ` ` (2 spaces)
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#doc_overindented_list_items
note: the lint level is defined here
--> crates/arti-rpc-client-core/src/lib.rs:8:9
|
8 | #![warn(clippy::all)]
| ^^^^^^^^^^^
= note: `#[warn(clippy::doc_overindented_list_items)]` implied by `#[warn(clippy::all)]`
```
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Its underlying function previously took `&mut RpcHandle`,
which was an accident waiting to happen. Now it takes `&RpcHandle`
and includes a Mutex to prevent multiple threads from waiting for
updates on the same request ID at once.
As an alternative, we *could* try to update connimpl::Receiver to
allow multiple simultaneous listeners on the same request ID.
But that would (I think) require a lot more bookkeeping, and thus
would be a bit more error-prone.
Closes #1532.
|
| |
|
|
|
|
| |
This lets us make a couple of types module-private,
and prepares the way for using the serde_json::Value trick on
requests too.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
