New zero alloc, no_std compatible implementation

[h33p]

Thanks a lot for this great crate! I wanted to see if one could make pollster work in no_std environments, since for one of my upcoming async libraries having option to run without standard library is key, and I noticed that there already is a PR getting rid of complex synchronization mechanisms like condition variables in #9.

The use of thread_locals to avoid locking was really interesting, but that made pollster even harder to support no_std, so I took inspiration from that implementation and looked for a way to have the best of all worlds - no dependency on std or alloc.

This implementation relies on the fact that the Thread is cloneable and layout-compatible with a pointer (in fact, it's an Arc), thus one may just build a Waker out of the thread without unnecessary wrapping behind Arcs.

Is this safe? It depends on you, but my view is that it's safe enough, because:

a) Thread relies on having constant memory location and I see no reason why the layout should change anytime soon.
b) Even if the layout changed, it would not lead to unsafety. Instead, the compiler would refuse to compile the crate with std feature enabled due to sizes in mem::transmute mismatching.

But I'm not sure what you think, it's a hack, and it would ideally be nice to work towards support for taking a "thread pointer" and construct a thread handle from that in the standard library, but right now there are no such facilities available, thus it is as good as it gets.

[zesterer]

Thanks for the PR! @fereidani how much overlap do you think this has with your PR?

This implementation relies on the fact that the Thread is cloneable and layout-compatible with a pointer (in fact, it's an Arc), thus one may just build a Waker out of the thread without unnecessary wrapping behind Arcs.

Interestingly, I used a very similar approach in this PR, but was unconvinced of the soundness of this approach since Thread is not a transparent wrapper around Arc: #8

Is this safe?

Unfortunately, it is not. Although this happens to work today, on the setup we're using, it is UB and for that reason I wouldn't be happy putting this into a crate used by so many people. That doesn't mean that it's not a potential avenue for exploration, though.

[fereidani]

Nice implementation and ideas!
But I'm unsure about unsafe parts.
I'll update my PR with some similar ideas so we can discuss and see what is the best solution for the pollster.