summaryrefslogtreecommitdiff
path: root/crates/tor-events
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'readme_fixes'Nick Mathewson2021-11-301-12/+1
|\
| * run ./maint/readmes.shdagon2021-11-291-12/+1
| |
* | Bump every crate by one patch version.Nick Mathewson2021-11-291-1/+1
| |
* | add semicolons if nothing returnedDaniel Eades2021-11-251-0/+1
|/
* Remove a couple more eprintln! calls.Nick Mathewson2021-11-231-1/+0
|
* Add and resolve clippy warnings in tor-events.Nick Mathewson2021-11-222-0/+40
| | | | | Here we add the same array of clippy warnings as usual to the new tor-event crate, and resolve the issues that triggered any of them.
* Initial cut at a typed event framework for arti (arti#230).eta2021-11-224-0/+425
This implements a basic typed event broadcast mechanism, as described in arti#230: consumers of the new `tor-events` crate can emit `TorEvent` events, which others can consume via the `TorEventReceiver`. Under the hood, the crate uses the `async-broadcast` (https://github.com/smol-rs/async-broadcast) crate, and a `futures::mpsc::UnboundedSender` for the event emitters; these are glued together in the `EventReactor`, which must be run in a background thread for things to work. (This is done so event sending is always cheap and non-blocking, since `async-broadcast` senders don't have this functionality.) Additionally, the `TorEventKind` type is used to implement selective event reception / emission: receivers can subscribe to certain event types (and in fact start out receiving nothing), which filters the set of events they receive. Having no subscribers for a given event type means it won't even be emitted in the first place, making things more efficient.