Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
KS2010: Core kernel vision
Posted Nov 2, 2010 12:50 UTC (Tue) by michaeljt (subscriber, #39183)
What is the race with notification? Or what races are there that can't be fixed by a second notification and no guarantee that no spurious notifications are sent?
Posted Nov 2, 2010 13:06 UTC (Tue) by michaeljt (subscriber, #39183)
> What is the race with notification? Or what races are there that can't be fixed by a second notification and no guarantee that no spurious notifications are sent?
One answer to myself: http://lwn.net/Articles/361566/ points out that inotify doesn't let you exclude changes to files that you caused yourself, so that if you update a file every time it is modified you will get into a loop. Sounds like a somewhat specialised use case, but I'm sure that there is a good reason for it.
Posted Nov 4, 2010 9:14 UTC (Thu) by liljencrantz (guest, #28458)
That sounds very much like how you have to re-call syscalls that were interruped by a signal. Is it a pain that you have to replace every call to close with a loop that breaks if errno != EINTR? Sure. But handling everything transparently is just way too complex, so some complexity is pushed onto the user. Sounds like inotify does the same. I see zero problem with that.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds