Because distributors are usable globally by name, it's possible (and
useful) for multiple groups of children to use the same distributor.
However, if one of the groups of children is then stopped as part of the
normal flow of an application, the distributor is removed from the
global dispatcher, and all senders receive an error on trying to send to
that distributor, even if it still has active recipients from other
groups of children.
This commit changes `remove_distributor` in the global dispatcher so
that it checks to see if it still has recipients and only removes the
distributor if there are no remaining recipients.
* proposal: distributor request fn
* go async by default, add a sync variant backed by mpsc::channel
* let the example runwith or without the tokio-runtime feature
* fix: sometimes the children weren't attached to the dispatcher
* use RwLock for now
* add an after_start callback to know exactly when the children have spawned and the distributor is ready to receive and dispatch messages to everyone
* wip
* merge tests
* split the tokio and the regular test runner so that both pass
* wip
* wip, a lot left!
* a bit of debug statements and more funsies
* tell and tell_everyone are working.
* ok we're almost there, lets see if i can handle a vec<replies> and if i can register ppl to a new Distributor
* yay it works!
* lints
* 19 lints remaining
* 9 warnings to go
* docs + tests
* i think we re good to go
* example fix
* san
* move miri to a .sh file
* bump nightlies and anyhow
* clippy pass + prepare to merge
Previous pull request[1] introduced the MessageHandler datatype, but did
not export it in the prelude.
Examples have been updated so that they don't import MessageHandler manually.
[1]: https://github.com/bastion-rs/bastion/pull/309
* Add initial implementation for MessageHandler
This commit adds very basic implementation of MessageHandler. This structure
stores a SignedMessage, and calls, depending on which kind of message it is, and
on its underlying type, either a specified closure, or a fallback one.
The goal is to provide an API that would be nicer to work with than the msg!
macro.
Current implementation features a state-machine like algorithm and currently
only handles messages that can responded to (aka "questions").
* Make AnswerSender carry its own signature.
This allows us not to trust caller of AnswerSender::reply to provide a
correct signature. As such, the corresponding method can be documented.
This is necessary because such method may be called in the closure that
are passed to MessageHandler::with_question.
Note: this commit renames AnswerSender::send to AnswerSender::respond, and
removes the signature part. This method is public but not documented. As
such, this theorically breaking change should not break any code.
* Add on_* functions
This allows us to match on both regular messages (the ones we can't
respond to) as well as the broadcasts. It follows the same model
established previously.
* Add documentation for MessageHandler API
* Make sender address available for each on_* function
* Allow MessageHandler to return something
Previous implementation of MessageHandler always returned nothing, as it
was not considered important. However, returning something is important
at least in the fibonacci example.
This commit allows the MessageHandler to return some data. It requires
every matcher to return the same data type. This data is stored in the
MessageHandler and returned by the on_fallback function.
* Rewrite the fibonacci example with MessageHanlder
* Remove useless clone by destructuring on fallback.
This allows us to remove additional code.
* Add a proof of concept that we can match over different types using the MessageHandler
Co-authored-by: Jeremy Lempereur <jeremy.lempereur@gmail.com>
Transitioning to intra-doc-link will allow us to get better feedback about broken
links in the future. It also allows us to remove some annotations that are guessed
by rustdoc.
This commit *should* translate every link to intra-doc-link.
* wip, allow to run tokio based futures in the bastion executor
* use tokio::main!
* runtime handles
* wip, adding tests and making them compatible with runtime-tokio
* ok docs remaining, no clue how to handle it
* wip, doctests
* wip: getting there...
* tests are finally passing!
* runtime-tokio => tokio-runtime
* tokio_test is amazing <3
* woopsie
* prepare for master, so we can beta test the tokio feature