async-rs / async-std

Async version of the Rust standard library
https://async.rs
Apache License 2.0
3.96k stars 340 forks source link

TCP connections don't work on wine #943

Open skade opened 3 years ago

skade commented 3 years ago

I'm a bit in rush. There seems to be an issue with async-std/smol/wepoll under wine, which is rooted in usage of an undocumented windows API that wine doesn't support.

https://bugs.winehq.org/show_bug.cgi?id=50520 https://github.com/tokio-rs/mio/issues/1444#issuecomment-766396117

yoshuawuyts commented 3 years ago

smol relies on wepoll to work, and the wepoll maintainer has replied here that this is in fact due to missing emulation in Wine. The exact details don't matter too much, but the conclusion appears to be that this would take non-trivial effort to address, which may not happen anytime soon.

One option we could perhaps employ though would be to fall back to a thread-pool based implementation on Wine (based on blocking + std::net::TcpStream). It'd be slow, but at least it wouldn't panic. Which I'm guessing would be a step up from the current status quo.

The question is how to detect we're running under Wine though. Perhaps we could scan whether the syscall exists and then swap backends? Perhaps Wine has a canonical way to allow people to detect it? We should probably figure that out since we shouldn't default to using the thread pool for all Windows targets.

greaka commented 3 years ago

AFAIK Wine has a few env vars set that make it obvious. I don't know about the threadpool idea though. It might catch ppl by surprise.

yoshuawuyts commented 3 years ago

I don't know about the threadpool idea though. It might catch ppl by surprise.

By default our async FS operations already run on a threadpool; this will change with io_uring / ringbahn eventually but only as an enhancement if we detect the OS has support for it.

I'm curious though: is the worry that the performance may not be good enough? Would it be enough if we documented this clearly? Mostly thinking that having something working is better than simply not running and offloading the fix onto end-users. As I understand it nobody really expects Wine to run with similar performance as native Windows; as long as it's not unusably slow it's generally fine. But maybe my understanding there is wrong?


AFAIK Wine has a few env vars set that make it obvious.

Yay! We should probably find out which env vars those are.

greaka commented 3 years ago

I don't know much about async-std, as I mainly use smol. So I didn't know that FS is already using a thread pool. I think Wine is mostly used for games, but I don't know what the priorities for most developers are in that case. A threadpool definitely sounds better than crashing or blocking though.

Take my comment just as from someone who has no idea what they are talking about 🙂

coderedart commented 3 years ago

https://github.com/tokio-rs/mio/issues/1444#issuecomment-867685922

notgull commented 1 year ago

This may still be an issue. Wine on Ubuntu 22 still uses 6.0.3, and Debian Stable is still on version 5.