Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File a issue with the standard library? #18

Open
moonheart08 opened this issue Mar 23, 2020 · 14 comments
Open

File a issue with the standard library? #18

moonheart08 opened this issue Mar 23, 2020 · 14 comments

Comments

@moonheart08
Copy link

If this is feature equivalent, wouldn't it be a good idea to try and get it merged into std?

@Restioson
Copy link
Collaborator

There has been some talk on the T-libs Zulip about this, so it's definitely a goal! Currently we are fixing some bugs and trying to optimize so that we don't perform so poorly compared to crossbeam for low-bound bounded channels, rendezvous channels, and SPSC channels. Here is what the benches currently look like (0.7.1). We are beating std in almost all the benches but we have the aforementioned areas of weakness.
image

@zesterer
Copy link
Owner

zesterer commented Apr 8, 2020

Here are the latest numbers from the flavour-refactor branch (Linux, AMD Ryzen 7, 4 cores, 8 threads).

image

@Ericson2314
Copy link

Was there any more progress on this? I am possibly interested in helping out.

@Ericson2314
Copy link

I suppose the first challenge is that there isn't an optional std feature for flume (i.e. no-std + alloc or whatever support), and I am not sure how one could make one without breaking up std into more crates first (because of std::thread usage, etc.)

@Restioson
Copy link
Collaborator

Yea. I think it would probably need to be source copied into std because of this?

@Ericson2314
Copy link

Well then it's liable to stagnate; I prefer approaches were std can just use the crates.io crate to better leverage the good work being done in the ecosytem on an ongoing basis :).

@zesterer
Copy link
Owner

I've an in-progress refactor that builds the channel on top of a no-std, async core. I believe that this could act as the step necessary to facilitate porting to std. However, it's not finished yet.

@Restioson
Copy link
Collaborator

So the idea then would be that std would use the core and wrap it (in house) with synchronicity primitives to fit in the mpsc api?

@zesterer
Copy link
Owner

Yes, I think that's the most reasonable approach.

@Ericson2314
Copy link

Ericson2314 commented Jun 16, 2021

Oh, nice! Looking forward to seeing that. Even as a heavily WIP draft PR :).

@Ericson2314
Copy link

Ericson2314 commented Jul 7, 2021

@zesterer Any luck? Maybe want to open a WIP PR?

@zesterer
Copy link
Owner

zesterer commented Jul 7, 2021

I've not done a huge amount of work on the branch and it still has a few subtle issues that need resolving (mostly relating to async usage). However, I can open a PR for discussion about it.

@zesterer
Copy link
Owner

zesterer commented Jul 7, 2021

I've opened a draft PR here.

I don't know how much time I'll get to work on this. If you or someone else wants to work on resolving some of the issues, I'd be very happy to accept PRs!

@Ericson2314
Copy link

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants