Welcome to crossfire-rs Discussions!

[frostyplanet]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

For real time conversation, please join our disord channel: https://discord.gg/YqZrBRPFxX

[zach-schoenberger]

Hi @frostyplanet , I was wondering if you would be open to exposing timeout send/receive calls for async/sync? I know the crossbeam api supports this under the hood, it would mostly be on supporting adding first class support for it on the async side.

[frostyplanet]

I have been trying some ideas in v2.1 branch, to improve async context switch performance, mostly unsuccessful so far. I might do some big changes to the Wakers. And that is related to size=0 support in bounded channel.

[frostyplanet]

@zach-schoenberger there's one case about timeout. Feel free to add more tests about it.
test_timeout_recv_async https://github.com/frostyplanet/crossfire-rs/blob/master/src/tests/test_async.rs#L253
Actually the behavior in test_basic_unbounded_idle_select() is also the same as timeout https://github.com/frostyplanet/crossfire-rs/blob/master/src/tests/test_async.rs#L153C10-L153C42
I have added a section in the wiki https://github.com/frostyplanet/crossfire-rs/wiki/Async-and-Future-basics#future-aborts
I think the current implementation can achieve no message loss when future aborts. But I am not quite sure, maybe a pressure test might be needed to confirm that.

[zach-schoenberger]

thanks for the quick reply! i'm familiar with the timeout function you linked, i just figured that adding the support directly into the future thats being created in crossfire might be a little more efficient. i was also hoping to expose this api on the sync side https://github.com/crossbeam-rs/crossbeam/blob/master/crossbeam-channel/src/channel.rs#L490. since that would be much better than trying to always use the select api on the sync side.

[frostyplanet]

@zach-schoenberger sounds good

[frostyplanet]

@zach-schoenberger I've created a dedicated page for timeout #11

[zach-schoenberger]

Kind of an odd question, but @frostyplanet would be open to adding clippy as a part of the gitops flow?

[frostyplanet]

clippy has too many option to configure, It only help if many contributors participate in an project. But only a restriction to only a few members. I have participate in other project with clippy before... It will warn even when you use std LinkedList (That's kind of funny), and it's unfriendly to unsafe code. (As a low-level project unsafe is necessary when you dig deeper)
I might spend more time fixing clippy warning than writing the code that really matters :( . The total amount of code is relatively small in this project, and I have been doing many failed experiments on lockless patten lately.