async-std icon indicating copy to clipboard operation
async-std copied to clipboard

TCP connections don't work on wine

Open skade opened this issue 4 years ago • 6 comments
trafficstars

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

skade avatar Jan 24 '21 17:01 skade

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.

yoshuawuyts avatar Jan 25 '21 11:01 yoshuawuyts

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.

greaka avatar Jan 26 '21 00:01 greaka

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.

yoshuawuyts avatar Jan 26 '21 12:01 yoshuawuyts

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 🙂

greaka avatar Jan 27 '21 10:01 greaka

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

coderedart avatar Jun 24 '21 14:06 coderedart

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

notgull avatar Nov 25 '22 23:11 notgull