Bug in mpsc channel

[ty]

Step to reproduce:

1. Run the example/ring.rs with RUST_BACKTRACE=1 cargo run --example ring -- 10 10 4
2. You would see one coroutine is panicked with message thread 'Processor #0' panicked at 'No coroutine is running yet', src/runtime/processor.rs:189

Stack trace:

stack backtrace:
   1:        0x10fc3c238 - sys::backtrace::tracing::imp::write::ha0f40157033dab87T8t
   2:        0x10fc3dbd5 - panicking::default_handler::_<closure>::closure.42228
   3:        0x10fc3d734 - panicking::default_handler::hfa48369cd11de99dKcy
   4:        0x10fc347e4 - sys_common::unwind::begin_unwind_inner::h1122abee381015baUbt
   5:        0x10fba5127 - sys_common::unwind::begin_unwind::h4158147814178406820
   6:        0x10fbbea24 - runtime::processor::Processor::take_current_coroutine::h4936822716245698684
   7:        0x10fbbb868 - sync::mpsc::Receiver<T>::recv::h2915722332526574509
   8:        0x10fbb7402 - create_node::_<closure>::closure.7216
   9:        0x10fbb6dea - coio::scheduler::Scheduler::spawn_opts::_<closure>::_<closure>::closure.7206
  10:        0x10fbb6cac - coio::try::_<closure>::closure.7202
  11:        0x10fbb6a67 - std::panic::recover::_<closure>::closure.7197
  12:        0x10fbb6a49 - sys_common::unwind::try::try_fn::h15552624096057116699
  13:        0x10fc3b7d8 - __rust_try
  14:        0x10fc3957e - sys_common::unwind::try::inner_try::h7ecee3e4b8b6ef00s8s
  15:        0x10fbb6a00 - sys_common::unwind::try::h17979100537356221247
  16:        0x10fbb685d - panic::recover::h3181483393315964186
  17:        0x10fbb67a7 - try::h9948958839926392203
  18:        0x10fbb65fa - coio::scheduler::Scheduler::spawn_opts::_<closure>::closure.7147
  19:        0x10fbbb265 - boxed::F.FnBox<A>::call_box::h13651452381535119350
  20:        0x10fc1283b - boxed::Box<FnBox<A, Output $u3d$$u20$R$GT$$u2b$$u20$$u27$a$GT$.FnOnce$LT$A$GT$::call_once::h9628849924945103469
  21:        0x10fc124fd - coroutine::coroutine_initialize::__rust_abi
  22:        0x10fc1247c - coroutine::coroutine_initialize::hfedf290f1e2da700O6c

As we can see, the Receiver::recv calls Processor::take_current_coroutine, which will panic because of Processor::current_coro is None.

This bug can only be reproduced with more than 1 processor.

[ty]

I found the bug. This is because the function haven't got the correct Processor instance. When the coroutine is waken up, the Processor::current() may not be the one that yielding him out. So you have to call Processor::current() again to get the correct Processor instance.