Description

I'm trying to add an ETCD backend storage, but I encountered some issues during the development process.

• When I'm establishing a connection to the ETCD cluster using the official ETCD development package etcd-client, I found that the methods provided by etcd-client are all async, while the methods defined in the backend are sync.
• Then I attempted to use tokio::runtime::Handle::current() to acquire the current Tokio runtime, and subsequently utilize the block_on method to block and wait for the async method's return result.
• However, Tokio does not permit calling the block_on method within an async context. So, I attempted to use the spawn method to execute the async method in a new thread, but I couldn't retrieve the return result of the asynchronous method.

            rt.spawn(async move {
                let resp = client.get(path.join("/"), None).await;
                if let Some(kv) = resp.kvs().first() {
                    Ok(Some(BackendEntry { key: kv.key_str().unwrap().to_string(), value: kv.value().to_vec() }))
                } else {
                    Ok(None)
                }
            })
  

• So I tried using tokio::sync::mpsc::channel to receive the result, but the recv method of Receiver still blocks the thread.

  let (send, mut recv) = tokio::sync::mpsc::channel::<String>(1);
  

• Even when I switched to using the block_on method from the feature package, it still blocks the thread.

  fn run_executor<T, F: FnMut(&mut Context<'_>) -> Poll<T>>(mut f: F) -> T {
     let _enter = enter().expect(
       "cannot execute `LocalPool` executor from within \
        another executor",
   );
  
   CURRENT_THREAD_NOTIFY.with(|thread_notify| {
       let waker = waker_ref(thread_notify);
       let mut cx = Context::from_waker(&waker);
       loop {
           if let Poll::Ready(t) = f(&mut cx) {
               return t;
           }
  
           // Wait for a wakeup.
           while !thread_notify.unparked.swap(false, Ordering::Acquire) {
               // No wakeup occurred. It may occur now, right before parking,
               // but in that case the token made available by `unpark()`
               // is guaranteed to still be available and `park()` is a no-op.
               thread::park();
           }
       }
   })
  }
  

• I also feel that there are some parts of the architecture that are designed in a less-than-ideal manner
  • The http_server itself is a blocking async method. Why does it need to be hosted in actix_rt::System, and moreover, actix_rt::System only hosts this single thread? Server
  • The http_handler is an async method, calling sync methods in Core, which in turn calls sync methods in Backend. Backend is a trait of storage backends, which may include async or sync methods. This threading model makes me feel somewhat confused.Handler,Storage

Related Issues

Resolves #26