Bug 215011 - kqueue: notification race condition between open and kqueue
Summary: kqueue: notification race condition between open and kqueue
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-02 17:54 UTC by myron.walker
Modified: 2023-01-03 23:52 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description myron.walker 2016-12-02 17:54:18 UTC
There is a race condition that must be worked around by everyone using kqueue(s) to monitor files for changes.  The race condition is.

1. open file and get fd
2. create kqueue to listen for events like (rename, delete, etc.)
3. go to sleep and wait for changes

The problem is that if the file is deleted or renamed in between the call to open
and before the kqueue is setup to monitor the file, you will not receive any notification

In order to work around this people do:

1. create/open file
2. check stat and path of file
3. create kqueue to listen for events
4. check stat and path of file again and make sure nothing changed
5. go to sleep and wait for changes.

It would be useful if there was a kqueue API for opening a file that would eliminate the race condition between opening a file and setting up monitoring an API that combines the parameters of open and kqueue so that the file descriptor returned and the kqueue monitoring setup will be atomic.  Maybe a 'kopen' api or something like that.

This would raise awareness of the race condition and provide a standard way of navigating around it that can be stabalized and utilized throughout code to provide support for a much more robust platform.