-
Hi, I'm interested in building a custom driver to have my Futures suspend in a non-blocking way where I'm able to wake the ones that are ready from a separate thread outside of the runtime. I've looked at how the I'd like to do something like that, but it's application-specific and I don't want to fork/modify the tokio library. I think the workaround is to have my centralized logic run a spin loop on a separate thread and continuously check the status of outstanding Wakers to see which ones I can activate. I won't be explicitly parked by tokio, so I have to anticipate new Wakers being submitted to my pseudo-driver, which is why I'd need an inefficient spin loop to notice these additions. The specific call I want to wrap is vkWaitSemaphores, which is a blocking call that accepts multiple objects (so multiple suspended futures can be batched into one call) with a timeout. It can be called with "wait for all" semantics like |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
Your idea of having a separate thread is a good one. Basically, you would write a custom impl of the As for noticing new additions to the set of semaphores, why not make a semaphore for that? Every time you've added a new waker, you add a permit on a special semaphore, which wakes up your thread. The thread can then check for new semaphores and go back to sleep. |
Beta Was this translation helpful? Give feedback.
Your idea of having a separate thread is a good one. Basically, you would write a custom impl of the
Future
trait that asks your dedicated thread to add the semaphore to its list of semaphores, also informing the thread which waker it should wake when the semaphore gets a permit. There is an example of waking a future from another thread here.As for noticing new additions to the set of semaphores, why not make a semaphore for that? Every time you've added a new waker, you add a permit on a special semaphore, which wakes up your thread. The thread can then check for new semaphores and go back to sleep.