kinghajj / deque Goto Github PK

Hi! The version on crates.io of deque doesn't compile on the current nightly, but the version on github does.

It would be great if you could make a new release :)

Would be great to have it :)

This may be obvious, but it would be nice to have an assertion on this.

Creating pull request to fix this as well.

An initial benchmark using coio-rs, which uses this crate to implement work stealing coroutine scheduling, suggests that using acquire/release ordering instead of sequential-consistent improves performance of this deque by up to 700% and overall performance of coio by about 3%, even though deque should play such a small part of the rest of the program (using OS X 10.11, i7 3770).

I'd be willing to create a PR based on this gist: https://gist.github.com/Amanieu/7347121 which in turn is based on this paper: http://www.di.ens.fr/~zappa/readings/ppopp13.pdf if you'd be ok with merging my changes and pushing a new version to crate. 😊

Intial size of deque is 32 but I guess there is no case handled for buffer size to increase above a certain threshold?

Hi,

I didn't read the C11 implementation that the last version was based on, so maybe I'm wrong here.

Previously I could clone a Stealer<T> even when T was not implementing Clone. With 0.3.0 I can't do that. Is this intentional or a bug? I need to be able to clone my Stealers for deques where the content can't be cloned.

src/workerthread.rs:73:22: 73:29 error: no method named `clone` found for type `deque::Stealer<Task<Arg, Ret>>` in the current scope
src/workerthread.rs:73         self.stealer.clone()
                                            ^~~~~~~
src/workerthread.rs:73:22: 73:29 note: the method `clone` exists but the following trait bounds were not satisfied: `Task<Arg, Ret> : core::clone::Clone`

I can submit a PR with a fix if it's a bug. If it's intended I would like to know why this has changed. Thanks.
Ping @Amanieu