Similar to wait1_for_callback! but will invoke the callback multiple times until
success. Users need provide a closure $request_fn that takes a user defined state and
produces a triple of (request_to_other, regex, new_state). If the request fails to produce
the matching regex, the closure will be invoked again with new_state instead of state.
This will continue until success or a finite number of failures has been reached.
create_ghost_channel outputs two endpoints,
a parent_endpoint, and a child_endpoint
these raw endpoints are not very useful on their own. When you get them
to the place they will be used, you probably want to call
as_context_endpoint_builder() on them.
GhostContextEndpoints allow you to drain these incoming GhostMessages
A GhostMessage contains the incoming request, as well as a hook to
allow a response to automatically be returned.
helper struct that merges (on the parent side) the actual child
GhostActor instance, with the child’s ghost channel endpoint.
You only have to call process() on this one struct, and it provides
all the request / drain_messages etc functions from GhostEndpoint.
a ghost request callback can be invoked with a response that was injected
into the system through the handle pathway, or to indicate a failure
such as a timeout
We want to create a two-way communication channel between a GhostActor
and its parent. create_ghost_channel will output two GhostEndpoint
structures, the first one is the parent side, the second is the child’s.
definition for a ghost request callback
note, the callback can be registered as 'static because the code
definition itself doesn’t depend on any specific instance lifetime
if you want to mutate the state of a struct instance, pass it in
with the handle or process call.
(see detach crate for help with self refs)