Open skade opened 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.
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.
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.
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 🙂
This may still be an issue. Wine on Ubuntu 22 still uses 6.0.3, and Debian Stable is still on version 5.
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