On 05/19/2014 05:55 PM, Howard Chu wrote:
Hallvard Breien Furuseth wrote:
> Right... Though I can think of one non-kernel possibility:
> Previous process wrote something and got killed - maybe while
> fsyncing the changes. Then rapidly open and closed another mdb
> env - and close(sync descriptor) waits for the old changes to be
> synced in order to decide whether to return success or failure.
That's nonsense.
POSIX defines no such behavior for close(). In particular, close()'s
success/failure result cannot depend on some other process's state.
There is no other process. The point would be that the system's
only descriptor to a file with outstanding syncs is being closed.
And I wasn't thinking of POSIX particular, just trying to think
of reasons an OS might want to wait in close().
But "non-kernel" I said was wrong, more like it might be found
in some spec and not just the source.
Anyway, it was just a loose guess about what to look for, I'll
survive being proved wrong:-)
--
Hallvard