Messages in this thread | | | From | "Frank Filz" <> | Subject | RE: [RFC PATCH 0/5] locks: implement "filp-private" (aka UNPOSIX) locks | Date | Mon, 14 Oct 2013 08:23:03 -0700 |
| |
> http://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2 > > > .html > > > > > > See the section entitled "First Implementation Past the Post". > > > > Interesting that Jeremy actually suggested the implementation should > > have had an arbitrary lock owner as part of the flock structure: > > > > "This is an example of a POSIX interface not being future-proofed > > against modern techniques such as threading. A simple amendment to the > > original primitive allowing a user-defined "locking context" (like a > > process id) to be entered in the struct flock structure used to define > > the lock would have fixed this problem, along with extra flags > > allowing the number of locks per context to be recorded if needed." > > > > But I'm happy with the lock context per kernel struct file as a > > solution, especially since that will allow locks to be sensibly passed > > to a forked process. > > > > Another next step would be an asynchronous blocking lock... > > Yes, please :-)
What model would be useful to you (and for what project)? One thing I could think of is since we have a file descriptor for each lock owner/file pair, we could do something like select on those descriptors, got to think about how that would actually work though... The vfs lock layer does inherently support a kernel call back when a blocked lock can be unblocked, so we just need to figure out the best way to hook that up to user space in a way that doesn't require a thread per blocked lock.
Frank
| |