Actually, I was thinking about reconsidering the implementation of the socket classes using generics all around. The amount of redundant code is starting to explode with the different runtimes and protocols being considered.

I just put out a release of the Netlink stuff, and don't have a whole lot of time to keep working on this crate right now, but perhaps you folks can consider how best to use one or the other of these two PRs, and/or combine them? Then, when I swing back around to this one, we can get it all merged?

@balattar do you have any comments on this?

...and, of course, there's still a matchingasync_io implementation that would need to be done 😃

I'm not very familiar with async-std but it looks like there's already some code related to CanFdSocket in there.

Is there any way we could get some form of CanFdSupport merged on the sooner side for tokio? It would be nice to be able to use this at work and not have my company maintain a fork.

Understood, but I'm working on this crate in my spare time, and literally took a week off work this month for the Netlink stuff, so don't have a lot of unpaid time to dedicate to it at the moment. But this will definitely be in the next release when I can swing back around to it.

Well I'd love to help out, and I don't have to take time off of work to do that :)

I knocked out one of the other open-source crates last night, and thought to give this a try before moving on to the next one...

But I'm getting intermittent failures of the unit tests. Like this:

running 16 teststest dump::test::test_simple_example ... oktest frame::tests::test_bit_flags ... oktest errors::tests::test_errors ... oktest dump::test::test_extended_example ... oktest frame::tests::test_data_frame ... oktest dump::test::test_fd ... oktest frame::tests::test_defaults ... oktest frame::tests::test_error_frame ... oktest frame::tests::test_fd_frame ... oktest frame::tests::test_frame_to_fd ... oktest frame::tests::test_remote_frame ... oktest nl::rt::tests::test_as_bytes ... oktest tokio::tests::test_receive ... oktest tokio::tests::test_receive_can_fd ... oktest tokio::tests::test_sink_stream_fd ... FAILEDtest tokio::tests::test_sink_stream ... FAILEDfailures:---- tokio::tests::test_sink_stream_fd stdout ----Sent 3 framesthread 'tokio::tests::test_sink_stream_fd' panicked at src/tokio.rs:442:9:assertion `left == right` failed  left: 0 right: 2note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace---- tokio::tests::test_sink_stream stdout ----Sent 3 framesthread 'tokio::tests::test_sink_stream' panicked at src/tokio.rs:403:9:assertion `left == right` failed  left: 4 right: 2failures:    tokio::tests::test_sink_stream    tokio::tests::test_sink_stream_fdtest result: FAILED. 14 passed; 2 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00serror: test failed, to rerun pass `--lib`

The existing test failed once. The new FD test fails like 50% of the runs I tried.

I'll look at the tests, since the original one seems flawed. But do you have any ideas? Do the tests work for you consistently?

Oh, wait... Nevermind. I see it.

The new FD tests are running in parallel (at the same time) with the old ones and they're all reading and writing tovcan0 and interfering with each other at random.

There are a couple ways to solve this, but one way we're already using is theserial_test crate, which allows you to mark a test as#[serial]. All tests marked as such run one at a time so they don't clash.

When I did that with the tokio tests, they all started passing consistently.

Looking good.

Hey thanks!