Andy Caldwell

> Exposing each timer separately? I'm not sure I follow. Maybe you were referring to what I'm about to describe, but: I meant exposing `hyper_timer *` similar to `hyper_io *`....

> Yea, I think I'm generally fine with all you've proposed. I'd just like to track its stabilization differently from the client FFI. Basically, I don't want us to have...

Hi @seanmonstar! Hope all's going well. Investigations and implementation is continuing and they threw up an interesting problem that I wanted to flag with you. The basic problem is that...

Coming back to those additional thoughts, I've come to the conclusion that it's better to be consistent everywhere, so `hyper_task` now takes an optional `drop_callback` and setting the userdata twice...

Coming back to this, I've merged the latest master in to this branch and fixed up the discrepancies. Do you think you'll be able to review this soon to prevent...

Build failure was due to my rustc allowing nightly features by default, I've marked the benches that use `#![feature(test)]` as also needing `#![cfg(feature = nightly)]` so they won't get built...

Playing around, it seems that the `await` is only treated as covered if the future yields underneath it, the following forces a yield: ``` #[allow(dead_code)] #[derive(Debug, Default)] struct Yield {...

Note that `Yeild` is available in `tokio` as `tokio::task::yeild_now()` (https://docs.rs/tokio/latest/tokio/task/fn.yield_now.html). An implementation slightly closer to what you originally pitched (where you wrap a future in an adaptor) might look like:...

Minimal reproduction at https://github.com/bossmc/repro-buildkit-2204. System information: ``` $ docker version Client: Docker Engine - Community Version: 20.10.7 API version: 1.41 Go version: go1.13.15 Git commit: f0df350 Built: Wed Jun 2...

The build works if the local image is tagged and the build references it by the tag - that doesn't create any special registry/"distribution digest" as far as I know...