Task Waking without the overseer about route-rs HOT 3 CLOSED

After some preliminary testing on this issue. I feel like this is the issue that causes the need for the overseer, though it seems that the single shared rendezvous used for transmitting both task handles may also be untenable.

The test worked as follows. I gave both the provider and consumer of an AsyncElementLink a Sender and Receiver handle into a bounded channel that takes things of type Task. The crucial observation we saw was that with two channels both the provider and consumer could have their task handles parked in their respective waking channels, go to sleep, and cause a deadlock. To remedy this issue, I instead only created one bounded channel of size one. Logically, with only one slot total to place a Task into, there cannot be two parked tasks. Taken from the consumer side, when it notices a full packet channel, it should try to awaken the provider and then go to sleep. The consumer is now awaiting the provider to remove some packets from the channel so it can continue to make forward progress.

With only one channel, the general strategy to sleep would be:

1. Gather current task handle
2. Try to send task handle onto task rendezvous.
   a. No error: go to sleep
   b. Error::Full(), proceed to step 3
   c. Error:Disconnected, schedule self to awaken again. Maybe panic!?
3. Rendezvous is full, implying the provider is asleep, try_recv() from rendezvous to make space for our task handle.
4. Now we have the provider task handle, retry try_send() with our task handle onto the rendezvous.
5. Call provider_task.notify() then go to sleep.

We would think this would resolve the deadlock, since only one of the sides could be asleep awaiting the other at a time, but this code has an error. In step 2, where we get a trySend::full() error, we then immediately try_recv() the task in the channel, so we can send ours onto the channel. Unfortunately, we get the error on try_recv() that the channel is empty! This implies something is wrong with our model on how channels work, and we may need to use something more exact to make sure this deadlock doesn't happen.

I also disabled the overseer for my tests, so the only two things that can talk to the task rendezvous is the consumer and provider.

from route-rs.

I want to try using https://docs.rs/crossbeam/0.7.2/crossbeam/atomic/struct.AtomicCell.html instead of a channel to store the Task. I think I can use the swap function to do what we want and resolve the deadlock.

from route-rs.

The above AtomicCell works, the code is in progress of getting cleaned up for PR. Will probably push three PRs, one for each Link type.

from route-rs.