| |||||||||||||
KS2010: Core kernel visionKS2010: Core kernel visionPosted Nov 2, 2010 13:06 UTC (Tue) by michaeljt (subscriber, #39183)In reply to: KS2010: Core kernel vision by michaeljt Parent article: KS2010: Core kernel vision
>> The problem is in Unix filesystems themselves. They are too racy to do anything guaranteed to work.
> 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.
(Log in to post comments)
KS2010: Core kernel vision Posted Nov 4, 2010 9:14 UTC (Thu) by liljencrantz (subscriber, #28458) [Link]
So you do a check in the userspace code.
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.
|
|||||||||||||