async-std
async-std copied to clipboard
async-rs
Abstract unix sockets on Linux platform
This would be at least very useful for D-Bus on Linux. Although newer software/distros (systemd-based) do not make use of abstract sockets, dbus-daemon by default still uses abstract unix sockets. It would be nice to support these for backwards compitibility. There is an issue on std for this as well with more details.
We've generally been conservative in what we add, limiting ourselves to only the scope of the stdlib and extensions that are specific to async programming (such as timeout and concurrency). But I'm starting to wonder if we could be a bit more forward in that regard, and introduce extensions that would make sense to propose in std as well.
@zeenix do you maybe have a design outline for what this API would look like? That'd be massively helpful in determining the scope of this addition. The same would apply to #624 too.
We've generally been conservative in what we add, limiting ourselves to only the scope of the stdlib and extensions that are specific to async programming (such as timeout and concurrency). But I'm starting to wonder if we could be a bit more forward in that regard, and introduce extensions that would make sense to propose in
stdas well.
Cool.
@zeenix do you maybe have a design outline for what this API would look like? That'd be massively helpful in determining the scope of this addition. The same would apply to #624 too.
TBH I haven't yet thought of that. I'll do that and come back to you on this. :) In the meantime, if you've some ideas already, please do share.
Reading the manual page, the first thought that came to mind was to do it the same way as Linux does it but that doesn't map nicely at all to idiomatic Rust and will require changes to Path API itself. How about a Linux-specific constructor to UnixStream instead:
pub async fn connect_abstract(name: OsStr) -> Result<UnixStream>
Looking at the source, it should not be hard to implement in std at least. Currently it seems asyc-std relies on std API so if we go this way, this has to be added to std first, which is not a bad thing IMO. WDYT?
Oh and with this solution, UnixListener will also need a new constructor:
pub async fn bind_abstract(name: OsStr) -> Result<UnixListener>
I would also be interested in this feature. Since the tracking issue on std is entering its final comment period, how are the plans to port this to async-std as well? =)
