Async-std: Make `blocking` public?

[zkat]

Hi! I was using async-std in my cacache library. One of the things that I'm trying to do is implement AsyncWrite for it, but it turns out I'm using a tmpfile library that does sync i/o. Because of that, I pretty much copy-pasted the AsyncWrite impl for async-std's File, and it turns out with the latest version, task::blocking is now private, so I can't just... do that. (To clarify, I was using async-std pre-release, when I needed to use async-pool for this, and I just started porting the code over tonight when I ran into this).

For the sake of compatibility, it would be nice to have this available. My code that's doing this is over here, in case there turns out to be a Better Way™ to do what I'm trying to do that hopefully doesn't involve reimplementing tmpfile logic: https://github.com/zkat/cacache-rs/blob/zkat/async/src/content/write.rs#L147-L256

Cheers!

[sdroege]

It would also be quite useful for me to have the task::blocking module public. It could be re-implemented externally around a thread pool and oneshot channels of course, but doing that everywhere seems a bit suboptimal (performance- and code duplication-wise).

It's pub(crate) since the very first commit in this repo, so the rationale why it is not public anymore is lost from history unfortunately.

I assume it's not public anymore because there was not enough certainty that this is a good enough API to be stabilized as 1.0 soonish? Were there specific concerns about it? To me it looks like exactly how you'd expect such an API to look like.

[sdroege]

Maybe (also in relation to https://github.com/async-rs/async-std/issues/60), it would make sense to at least give access to some internals and "uncertain-if-good-enough-for-1.0"-APIs via a feature flag.

That way there can be some experimentation with the API and it isn't required for everybody to duplicate the implementation.

[yoshuawuyts]

This has come up several times, and we need to come up with a public API for this. This seems something we'll want to do in the medium term for sure; though we could cheat it by introducing the current API as "unstable" first (which seems almost guaranteed like it would change).

@stjepang do you have any thoughts?

[dvc94ch]

Can you also expose the net::driver::Watcher? I'm currently trying to async signal handling to work properly. The signal-hooks crate implements Evented, so it would be useful to be able to wrap that in the Watcher. The other thing I'm trying to get to work is flock. Not sure what the best way to do that is. Either implementing Evented or just using blocking.

[dignifiedquire]

:+1: on exposing net::driver::Watcher, implementing #22 using similar techniques as tokio-process uses, requires to use signal-hooks or sth similar, so this is somewhat blocked on this, unless the signal handling is pulled into here (bad idea imho though)

[yoshuawuyts]

I've filed #251 for the blocking function. We'll need to come up with something else to expose driver though (got some ideas; but got to test them out first.)

Hope this helps!