Hello,
I tried to run an application and saw that there are a few unimplemented features, such as: 00d0:fixme:file:NtLockFile I/O completion on lock not implemented yet
I was reading the developers guide and wanted to say hello to the mailing list.
Hello Owen, welcome to Wine!
On 9/11/22 08:49, Owen Hogarth wrote:
Hello,
I tried to run an application and saw that there are a few unimplemented features, such as: 00d0:fixme:file:NtLockFile I/O completion on lock not implemented yet
I would advise against trying to implement this—firstly because, despite showing up in many applications, it's not actually known to break anything, and secondly because it's actually quite hard if not impossible to implement (POSIX has no way to wait for a mandatory lock, for instance).
In general it's better to look for an actually broken application, and try to debug and fix it.
--Zeb
On Mon, Sep 12, 2022, 6:49 AM Zebediah Figura zfigura@codeweavers.com wrote:
Hello Owen, welcome to Wine!
On 9/11/22 08:49, Owen Hogarth wrote:
Hello,
I tried to run an application and saw that there are a few unimplemented features, such as: 00d0:fixme:file:NtLockFile I/O completion on lock not implemented yet
I would advise against trying to implement this—firstly because, despite showing up in many applications, it's not actually known to break anything,
Yes, and many of the other fixmes you have probably already have stub implementations sensible enough for most applications to work.
and secondly because it's actually quite hard if not
impossible to implement (POSIX has no way to wait for a mandatory lock, for instance).
We don't use POSIX locks to implement file locks; they are emulated entirely in the server, which I guess is specifically designed to avoid that problem with POSIX file lock semantics. Thus, this won't be *that* hard to implement; nonetheless, asynchronous I/O is not really easy to implement in general, especially for those new to wine codebase.
I recommend sending in a fix once you find something that is actually broken. ;)
In general it's better to look for an actually broken application, and try to debug and fix it.
--Zeb
On 9/11/22 19:38, Jin-oh Kang wrote:
and secondly because it's actually quite hard if not impossible to implement (POSIX has no way to wait for a mandatory lock, for instance).
We don't use POSIX locks to implement file locks; they are emulated entirely in the server, which I guess is specifically designed to avoid that problem with POSIX file lock semantics. Thus, this won't be *that* hard to implement; nonetheless, asynchronous I/O is not really easy to implement in general, especially for those new to wine codebase.
I don't see where you're getting that; we do indeed use POSIX locks. See set_unix_lock() in server/fd.c. I did incorrectly use the term "mandatory", though; we don't set mandatory locks on a file.
On Mon, Sep 12, 2022, 9:46 AM Zebediah Figura zfigura@codeweavers.com wrote:
On 9/11/22 19:38, Jin-oh Kang wrote:
and secondly because it's actually quite hard if not impossible to implement (POSIX has no way to wait for a mandatory lock, for instance).
We don't use POSIX locks to implement file locks; they are emulated entirely in the server, which I guess is specifically designed to avoid that problem with POSIX file lock semantics. Thus, this won't be *that* hard to implement; nonetheless, asynchronous I/O is not really easy to implement in general, especially for those new to wine codebase.
I don't see where you're getting that; we do indeed use POSIX locks. See set_unix_lock() in server/fd.c.
I stand corrected.
There's no poll() for file locks, so it would have to busy-wait anyway.
I did incorrectly use the term
"mandatory", though; we don't set mandatory locks on a file.
-
Jin-oh Kang -
Owen Hogarth -
Zebediah Figura