Recent Features
| |||||||||||||
KS2010: Core kernel visionKS2010: Core kernel visionPosted Nov 2, 2010 12:50 UTC (Tue) by michaeljt (subscriber, #39183)In reply to: KS2010: Core kernel vision by Cyberax 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?
(Log in to post comments)
KS2010: Core kernel vision Posted Nov 2, 2010 13:06 UTC (Tue) by michaeljt (subscriber, #39183) [Link]
>> 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.
KS2010: Core kernel vision Posted Nov 4, 2010 9:14 UTC (Thu) by liljencrantz (guest, #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.
|
|||||||||||||