On Sat, Oct 12, 2013 at 11:12:03AM -0700, Frank Filz wrote: > > This blog post of Jeremy's explains some of the history: > > > > > > 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 :-) Volker -- SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen phone: +49-551-370000-0, fax: +49-551-370000-9 AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen http://www.sernet.de, mailto:kontakt@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
