Skip to content

🧵 zb: Use async versions of UnixStream when possible - #1798

Open
germaniuss wants to merge 3 commits into
z-galaxy:mainfrom
germaniuss:main
Open

🧵 zb: Use async versions of UnixStream when possible#1798
germaniuss wants to merge 3 commits into
z-galaxy:mainfrom
germaniuss:main

Conversation

@germaniuss

@germaniuss germaniuss commented May 22, 2026

Copy link
Copy Markdown

When connecting to a UnixSocket a blocking/threaded API is being used. This commit changes this to use tokio::net::UnixStream and Async<std::os::unix::net::UnixStream> when possible, preventing the use of extra threads. The windows version continues using the blocking/threaded API.

The connect_addr API is dropped since neither tokio nor async-io supports it. Instead, we use the connect functions in both environments, since they allow for abstract names when the path is prepended with '\0'.

Move the connection code to unix.rs for better future maintainability.

Closes #1796

@germaniuss
germaniuss force-pushed the main branch 2 times, most recently from 9ef832c to 318bda4 Compare May 22, 2026 11:30
@germaniuss germaniuss changed the title zb: Use async versions of UnixStream when possible ♻️ zb: Use async versions of UnixStream when possible May 22, 2026
@germaniuss

germaniuss commented May 22, 2026

Copy link
Copy Markdown
Author

@zeenix Can't check if windows functions correctly since I don't have it installed atm but I think everything should work fine. If you can give it a look and tell me if anything is not right. I've also moved the connect code to unix.rs since that is what is being done with Tcp and Unixexec and seemed easier to maintain than a lot of code in mod.rs.

@codspeed-hq

codspeed-hq Bot commented May 22, 2026

Copy link
Copy Markdown

Merging this PR will not alter performance

✅ 22 untouched benchmarks


Comparing germaniuss:main (0c38b23) with main (7e074ed)

Open in CodSpeed

@germaniuss
germaniuss force-pushed the main branch 2 times, most recently from 2e24e0e to 4b8e92e Compare May 22, 2026 14:53
@germaniuss

Copy link
Copy Markdown
Author

@zeenix So, can this be merged? I've been using the fork on my PC for a personal project and all seems to work fine. There was an issue with windows but it should be solved now.

@zeenix

zeenix commented May 24, 2026

Copy link
Copy Markdown
Contributor

@zeenix So, can this be merged?

I was on a work trip this week so didn't get to review but in any case, please be patient.

I've been using the fork on my PC for a personal project and all seems to work fine.

Great to hear.

There was an issue with windows but it should be solved now.

Cool. I'll check. @elmarco could you please look at this from Windows' perspective?

@zeenix

zeenix commented May 24, 2026

Copy link
Copy Markdown
Contributor

@zeenix So, can this be merged?

Multiple CI failures here, so this will need more work for sure. :)

@germaniuss

Copy link
Copy Markdown
Author

I was on a work trip this week so didn't get to review but in any case, please be patient.

Sure thing!

Multiple CI failures here, so this will need more work for sure. :)

Yeah, I'll check again to see what's wrong here.

@germaniuss

Copy link
Copy Markdown
Author

@zeenix The CI issues should be fixed now.

@zeenix zeenix left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apart from these, please also choose a more appropriate emoji. ♻️ is for refactoring and that's not a good catagorization of the change.

Comment thread zbus/src/address/transport/unix.rs Outdated
Comment thread zbus/src/address/transport/unix.rs Outdated
Comment thread zbus/src/address/transport/unix.rs Outdated
Comment thread zbus/src/address/transport/unix.rs Outdated
Comment thread zbus/src/address/transport/mod.rs
Comment thread zbus/src/address/transport/mod.rs
@germaniuss

Copy link
Copy Markdown
Author

Addressed all of the comments. Not really sure what emoji I should use for the main commit though 🤔. Maybe ⚡️? Though I'm not sure since there is not a clear performance improvement.

@zeenix

zeenix commented May 24, 2026

Copy link
Copy Markdown
Contributor

Addressed all of the comments.

Thanks. I unresolved one though. I'm sorry to ask you to do more but I did describe the reason for the changes I'm asking for.

Not really sure what emoji I should use for the main commit though 🤔. Maybe ⚡️? Though I'm not sure since there is not a clear performance improvement.

I think it's more appropriate than ♻️ still and I think there is a tiny performance improvement from not launching threads. Having said that 🧵is probably the best here.

@zeenix

zeenix commented May 24, 2026

Copy link
Copy Markdown
Contributor

Addressed all of the comments.

Thanks. I unresolved one though.

Oh and the windows CI continues to be failing.

@germaniuss

Copy link
Copy Markdown
Author

Switched out the order of the commits. Going to find a windows PC to test out why its failing.

@germaniuss

Copy link
Copy Markdown
Author

@zeenix Not really sure if I like how that second commit turned out, but everything should be done now. Windows turned out to be more of a pain than I imagined.

@germaniuss germaniuss changed the title ♻️ zb: Use async versions of UnixStream when possible 🧵 zb: Use async versions of UnixStream when possible May 24, 2026
@germaniuss
germaniuss force-pushed the main branch 5 times, most recently from 7b21f3a to dd22bde Compare May 24, 2026 21:23
@zeenix

zeenix commented May 25, 2026

Copy link
Copy Markdown
Contributor

@zeenix Not really sure if I like how that second commit turned out, but everything should be done now. Windows turned out to be more of a pain than I imagined.

Ouch, sorry! I actually was considering to drop the Windows support as I also don't have a machine to test it on but some people do use zbus on Windows. 🤷

Comment thread zbus/src/address/transport/unix.rs Outdated
Comment thread zbus/src/address/transport/unix.rs Outdated
Comment thread zbus/src/address/transport/mod.rs Outdated
Comment thread zbus/src/address/transport/unix.rs Outdated
Comment thread zbus/src/address/transport/unix.rs Outdated
Comment thread zbus/src/address/transport/unix.rs Outdated
Move UnixSocket connection code to unix.rs from mod.rs
for better readability and maintainability.

@zeenix zeenix left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work! I appreciate your patience and perseverance. 👍 I'm pretty sure the next iteration can be merged.

Comment thread zbus/src/address/transport/unix.rs Outdated
}

#[cfg(any(unix, not(feature = "tokio")))]
async fn get_stream(self) -> Result<UnixStream> {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need this change to be so intrusive and remove functions just added in the previous commit. Why not just simplify this method instead?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've readded the function and made it windows specific since from a maintainability point of view it seems the best for the eventual windows specific code removal.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems the best for the eventual windows specific code removal.

And to be fair, the UDS on windows support for Rust does seem to be going along quite well so maybe it's not so far off after all :D

Comment thread zbus/src/address/transport/unix.rs Outdated
Comment thread zbus/src/address/transport/unix.rs
When connecting to a UnixSocket a blocking/threaded API is
being used. This commit changes this to use `tokio::net::UnixStream`
and `Async<std::os::unix::net::UnixStream>` when possible preventing
the use of extra threads. The windows version continues using the
blocking/threaded API.

The `UnixStream::connect_addr` function from `SocketAddrExt` is
no longer used since neither tokio nor async-io supports it.
Instead, we use the plain `connect` functions in both environments,
since they allow for abstract names when the path is prepended
with '\0' (a null byte).
@germaniuss

Copy link
Copy Markdown
Author

Great work! I appreciate your patience and perseverance. 👍 I'm pretty sure the next iteration can be merged.

Great to hear! I rather appreciate the strict guidelines and expectation of code quality. That what makes open source have some of the best software out there!

// This is a `path` in case of Windows until uds_windows provides the needed API:
// https://github.com/haraldh/rust_uds_windows/issues/14
#[cfg(any(unix, not(feature = "tokio")))]
fn take_addr(self) -> Result<PathBuf> {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you're renaming a method in the last commit that you created in the previous one and the commit still seems more intrusive than it should be IMO. This commit should mostly just be replacing spawn_blocking use for unix in get_stream (which should exist for both configs) so the caller is simply abstracted from creation of stream and this commit becomes simpler and very much to the point.

@zeenix

zeenix commented Jul 9, 2026

Copy link
Copy Markdown
Contributor

Great work! I appreciate your patience and perseverance. 👍 I'm pretty sure the next iteration can be merged.

Great to hear! I rather appreciate the strict guidelines and expectation of code quality. That what makes open source have some of the best software out there!

Well?

@zeenix

zeenix commented Aug 20, 2026

Copy link
Copy Markdown
Contributor

Ping? You were so close.

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

Successfully merging this pull request may close these issues.

Zbus still spawns a second thread even with internal executor disabled

2 participants