Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TCP connections don't work on wine #943

Open
skade opened this issue Jan 24, 2021 · 6 comments
Open

TCP connections don't work on wine #943

skade opened this issue Jan 24, 2021 · 6 comments

Comments

@skade
Copy link
Collaborator

skade commented Jan 24, 2021

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
tokio-rs/mio#1444 (comment)

@yoshuawuyts
Copy link
Contributor

yoshuawuyts commented Jan 25, 2021

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
Copy link

greaka commented Jan 26, 2021

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
Copy link
Contributor

yoshuawuyts commented Jan 26, 2021

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
Copy link

greaka commented Jan 27, 2021

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
Copy link

@notgull
Copy link
Contributor

notgull commented Nov 25, 2022

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

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

No branches or pull requests

5 participants