This patch implements flock for Windows, needed to make gcda writing work in a multiprocessing scenario.
Details
Diff Detail
Event Timeline
lib/profile/WindowsMMap.c | ||
---|---|---|
131–132 | There is a subtle incompatibility here. If fd was originally opened for asynchronous IO, then this function will return immediately. This is basically the same as if you had called flock with LOCK_NB, but the difference is that with flock, the caller has to opt into it, where as with LockFileEx, it's an inherent property of the file descriptor. Actually, it's a bit more than just a semantic difference. Since the function will return immediately, the OS will be holding onto destroyed stack memory (i.e. the OVERLAPPED structure). I don't know if you want to handle this, but you should at least be aware, and perhaps leave a comment. | |
146 | I know you're only implementing part of the functionality, but why not all? Seems easy enough to handle LOCK_SH, just change LOCKFILE_EXCLUSIVE_LOCK to LOCKFILE_SHARED_LOCK and the code is the same. |
Updated patch to handle asynchronous I/O case and to implement all flock functionality as suggested.
It's better to implement it in its entirety and correctly handling all cases, otherwise problems in the future could be hard to debug, especially since we are talking about locking.
There is a subtle incompatibility here. If fd was originally opened for asynchronous IO, then this function will return immediately. This is basically the same as if you had called flock with LOCK_NB, but the difference is that with flock, the caller has to opt into it, where as with LockFileEx, it's an inherent property of the file descriptor.
Actually, it's a bit more than just a semantic difference. Since the function will return immediately, the OS will be holding onto destroyed stack memory (i.e. the OVERLAPPED structure).
I don't know if you want to handle this, but you should at least be aware, and perhaps leave a comment.