Rtnetlink fail

[little-dude]

This example show the current design flaws of rtnetlink:

• tokio is by nature multi-threaded, but that does not play nicely with linux namespaces
• rtnetlink is too verbose, and its API is ugly

The API can be fixed, but I'm less sure about the first point...

[pinkisemils]

Would using single-threaded runtime help at all? I'm not sure you'll be able to force the users of the library to use a specific runtime by using language constructs, but I think it'd be reasonable to tell users to use a single-threaded runtime.
In any case, I swapped the import statement to import current_thread::Runtime and now I get a completely different error.

[little-dude]

Would using single-threaded runtime help at all?

Most likely. I haven't tried it out though.

I think it'd be reasonable to tell users to use a single-threaded runtime.

Indeed but that's a pretty strict limitation.

I swapped the import statement to import current_thread::Runtime and now I get a completely different error.

Do you mind sharing it here?

[pinkisemils]

The example code still fails to open netlink-example file, but this time, with a funky tokio error.

"failed to open /var/run/netns/netlink-example: Custom { kind: Other, error: StringError("blocking annotated I/O must be called from the context of the Tokio runtime.") }"
I've not looked too deep into this, and this isn't my area of expertise, so maybe my naive optimism is misplaced, but I feel like this isn't a show-stopper and finding a nice-enough workaround is possible :)

Indeed but that's a pretty strict limitation.

Whilst true, this is a limitation that everyone has to workaround anyway. Somewhat related to the namespace issues - I know that if not now then at least at some point in history Docker used to spawn a new subprocess right before starting up a new container just to ensure that a single thread would ever be running at the time of spawning a container to workaround these same issues.

It just so happens that there's some state that's bound to a specific thread and the users have to be mindful of that. This doesn't mean that an eventloop that's dealing with spawning new interfaces in different namespaces can't interact with other event loops, it'd just take a futures::mpsc::channel to bridge them together.

[little-dude]

Failed to open /var/run/netns/netlink-example: Custom { kind: Other, error: StringError("blocking annotated I/O must be called from the context of the Tokio runtime.") }

I remember seeing this error and fixing it so that should be fixable.

The rest of your comment brought me a bit of joy, thanks :) I was really unhappy about this state of things and thought it was just poor design on my side.

For the record, I'm traveling until the end of May, with sometimes no computer or internet access for several days/weeks, so I won't really be working on this library until then.

[laarmen]

This sound like there's something in there that should not implement Sync. Perhaps the netlink socket itself? Or the file descriptors? Of course I'm guessing such a change would break quite a few things about the current API :-).

FYI, I was actually looking into adding the capability to specify the target network namespace when querying for network links, as it is possible since this patch has landed.

[cathay4t]

Not sure it is related or not. If I use join_all() to a lot(1000+) netlink async futures, it always fail on the 129 futures:

   thread 'main' panicked at 'range end index 44 out of range for slice of
   length 8', `netlink-proto-0.6.0/src/codecs.rs:176:64`

Problem gone, when I use await to each of them, but this is against the async design.