User: Password:
|
|
Subscribe / Log in / New account

KS2010: Core kernel vision

KS2010: Core kernel vision

Posted Nov 2, 2010 12:07 UTC (Tue) by michaeljt (subscriber, #39183)
Parent article: KS2010: Core kernel vision

> Indeed, he should have rejected dnotify and inotify as well. There comes a point, after two or three failed attempts, where one has to realized that an idea is just broken.

Does hard to get right necessarily imply broken? And if it is broken, what would the proper fix be? Always poll for file changes? Always require the user to check manually? Or is there just some fundamental insight into the problem missing?


(Log in to post comments)

KS2010: Core kernel vision

Posted Nov 2, 2010 12:39 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

The problem is in Unix filesystems themselves. They are too racy to do anything guaranteed to work.

KS2010: Core kernel vision

Posted Nov 2, 2010 12:50 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?

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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds