Futures-rs: unsync is not in 0.2

[nayato]

Is there a reason why unsync (oneshot and mpsc) was left out moving to 0.2?

[pmarcelll]

They were moved to the futures::channel module.

[nayato]

@pmarcelll no, futures::channel::oneshot corresponds to futures::sync::oneshot from before while unsync version seems to be missing completely.
Are single-thread futures no longer a thing?..

[pmarcelll]

Sorry, you're right. I only found #766, which is a relatively new issue, and according to this, unsync should be part of the API, so it probably just wasn't ported yet.

[Pauan]

I am also using the unsync variants, because I'm compiling to WebAssembly which is (currently) single-threaded, so I want to avoid the overhead of synchronization.

[cramertj]

Unsync was intentionally removed for 0.2. We believe that users should default to using Sendable futures types, as they allow for compatibility with the default executor provided through cx.spawn, which requires Send.

[Pauan]

@cramertj Although I understand that reasoning, I think it's a real shame to force the extra overhead for use-cases that don't require it. It makes Futures seem less zero-cost.

In particular, our JavaScript / WebAssembly Executor runs on a single thread (therefore it doesn't require Send or Sync).

So requiring all Futures to implement Send simply because a particular Executor requires Send seems rather odd to me.

[fafhrd91]

That is strange decision, seems everyone will need to pay for using async. My framework actix-web is fully non-send, and making it Send will significantly reduce performance. It would be a shame to see performance drop after migration to new futures

[cramertj]

@fafhrd91

making it Send will significantly reduce performance

I'd be interested in seeing performance numbers if you have them available-- in my own tests, there wasn't a significant performance difference between Rc<RefCell<T>> and an uncontested Arc<parking_lot::Mutex<T>>, but if you're seeing different numbers, I'd like to know and take them into consideration.

[fafhrd91]

It is not about Rc vs Arc performance. I just relay on fact that future is non-send, and can use some unsafe code, with send it is not possible.

[cramertj]

@fafhrd91 Can you explain why you need to guarantee that the future is non-send? Feel free to also message me on gitter or IRC about this.

[nayato]

@cramertj (cc @aturon) having default executor is fine. But having it dictate what is supported seems like an unnecessarily narrow focus. It isn't clear for me if it's possible to implement unsync with new futures API but even if it is, having unsync left out of library means single-threaded concurrency will not be a first-class concept in futures and may be made impossible in the future revisions.
I'm coming from .NET where everything revolves around the default thread pool provided by runtime and having a different threading model is even made impossible with things like networking (e.g. Socket's async continuation will be called on a thread in thread pool with no way to override).
IMO the default here doesn't always fit (and arguably there are problems that do not require synchronization) and recognizing it in the library itself and having examples / modeling API to accommodate different approaches to threading would make for a healthier foundation for async programming in Rust.

[aturon]

To be clear, the intent was to offer the unsync primitives in a separate crate, just not include it in the default facade.

[nayato]

@aturon great to hear as long as it's part of the futures-* family.

[Pauan]

@aturon I'm completely fine with that, as long as it receives the same level of support and care as the rest of the futures-* ecosystem.

[aturon]

For sure!

[fafhrd91]

@cramertj I don't really need non-send guarantees, I just built my system around non-send code. as soon as I change everything to send I will need to do proper synchronization. and this seems like a useless work.

[cramertj]

@fafhrd91

as soon as I change everything to send I will need to do proper synchronization

This is sort of my point-- if libraries consistently structured themselves around being multithreading-compatible, then they wouldn't have to do any transition or build an interop layer in order to be used by users running mutithreaded executors.

If everyone used thread-safe types from the start, then all of these concerns about transitioning to Send types wouldn't exist.

[markazmierczak]

@cramertj

This is sort of my point-- if libraries consistently structured themselves around being multithreading-compatible, then they wouldn't have to do any transition or build an interop layer in order to be used by users running mutithreaded executors.

To me this is opposite. There are problems tied to be single-threaded. It makes little sense doing them thread-safe. I wonder what is a gain in tying every problem to multi-threaded scenario. For me it is only harder to develop. I agree public libraries should provide multi-threaded compatibility. But I see the gain in giving users single-threaded variant, especially when talking about something as basic as futures-channel.

[markazmierczak]

I feel I need to make additional point.
Asynchronous programming in general is not tied to either:

• single-threaded
• multi-threaded
  It ought to be developer ability to select which one to use.

In Java everything is tied to exceptions.
And I think we all agree that only the user of API knows if something is really exceptional.

The same case is with asynchronous programming and single- vs multi-threading.
Only the user of API knows what to use. If we select multi-threaded world for him, he might be forced to think about synchronization and Sent-ability - an additional, useless work.

[loyd]

futures 0.3 still doesn't include an unsync implementation of channels, I'm right?

[cramertj]

@loyd yes, that's correct.