add use_atomic feature

[ealasu]

Fixes #622

[alexcrichton]

Thanks for the PR! I'm pretty wary about this though as it basically turns off most of the library. I don't think we're quite ready to have a world without atomics and a futures crate right now, too much of the low level internals require atomics.

[carllerche]

What platform does not include atomics?

[ealasu]

@carllerche thumbv6m-none-eabi, which is used for microcontrollers based on ARM Cortex M0, M0+, and M1. The specific board I'm trying to use is an Arduino Zero.
Also see rust-lang/compiler-builtins#114 for basically the same issue in another crate.

[alexcrichton]

@ealasu I don't think we're going to be able to take this PR at this time. Most of this library is engineered around the existence of the task system which is itself engineered around the existence of atomics. It's sort of unclear how we would implement the library beyond the literal Future trait itself without the task system and atomics.

Is it critical that the futures crate as-is is usable in your context? I don't think you'd be able to use anything that depends on the futures crate because it all assumes a task system?

[ealasu]

@alexcrichton I've found the Future & Stream traits quite useful on their own, as an API for writing portable asynchronous code.
For example, in one project I'm implementing a stream/sink transform to add a reliable communication layer over a serial port:
https://github.com/ealasu/rust-keyboard/blob/master/framed/src/stream.rs
https://github.com/ealasu/rust-keyboard/blob/master/framed/src/sink.rs
Since it only depends on the Stream & Sink traits, the same code can run on both an embedded Cortex-M0 system and on a full-fledged Linux system. On Linux I'll use Tokio for the event loop, while on the embedded system I'll simply poll the stream/sink in a loop:

loop {
    while let Async::Ready(frame) = frame_stream.poll().unwrap() {
        // do stuff with frame
    }
    // do other stuff
}

If the futures crate didn't support the Cortex-M0 platform, it would be more difficult to write asynchronous code like this that supported both Cortex-M0 and tokio.

[alexcrichton]

Oh yeah I don't disagree that they can be useful abstractions, but my point is that in the case where you don't have a task system or any atomics at all I think the utility for a "shared abstraction" is greatly reduced, and it's effectively equivalent to having a local vendored trait at that point.

[ealasu]

There are some useful crates that depend on futures but don't need the task system, like futures-await.

[alexcrichton]

@ealasu sure yeah but in general this is something that's going to be very difficult to maintain over time. Most maintainers are pretty used to a std/core split but AFAIK few are used to atomic/no atomic splits. I, for example, have no experience maintaining a no-atomic platform.

[alexcrichton]

Ok I'm going to close this for now as I don't think we'll get very far in futures without atomics, but we can of course continue discussion in the issue tracker if you'd like!