The basic idea is to be able to do something like remote_call!([cx, actor], method(args));. However cx would have to be some kind of inter-thread object that forwards calls to the queue on the Stakker thread. Also actor can't be an Actor reference because that's not Send. So it requires something like a RemoteDeferrer and a RemoteActor. A RemoteDeferrer could be something like an Arc<Mutex<(Waker, Vec)>>. To avoid too much contention on a single mutex, it may be preferable to allow several underlying queues to be created, e.g. to create a different one for each thread it is sent to.

An alternative if only a few distinct calls are to be made would be to have a RemoteFwd, which is created from a Fwd and allows data to be forwarded to the Stakker thread. This would be something like an inter-thread stream with the destination fixed at creation time.

There is a question of how to handle failure. If the destination goes away (e.g. destination actor fails), then would the sender in another thread need to know about that? i.e. would they want to be notified to allow them to cleanup and terminate. The PipedThread implementation handles this case, meaning that if the actor holding the reference to the PipedThread dies, then the thread will also be notified to allow it to clean up and terminate. So probably RemoteActor and RemoteFwd should have a means to query whether the destination has gone away. Perhaps even make it hard for the caller NOT to notice, to force it to handle this case.

There is also the question on how this fits into future support for remote calls from further away than other threads, e.g. remote calls across machines. However it may be that remote calls from other machines will be handled with proxy actors, in which case it will be a completely different API and unrelated to this one.

Please add comments here if you have a requirement for something like this and what kind of solution would be preferable. (See also #23)