Date: Sat, 18 Dec 1999 23:08:48 -0500 From: "David E. Cross" <crossd@cs.rpi.edu> To: freebsd-hackers@freebsd.org Cc: crossd@cs.rpi.edu, perera@cs.rpi.edu Subject: NLM v4 (file locking and NFS v3) Message-ID: <199912190408.XAA45697@cs.rpi.edu>
next in thread | raw e-mail | index | archive | help
We have come across a problem wrt to a network file lock manager. Consider the case of a lock on a local file, and a request from a remote machine to lock that same file. fcntl(fd, F_SETLK, &fl) will return immediately with EAGAIN (this is for an exclusive case, of course), F_SETLKW will block (even if O_NONBLOCK has been set, this is annoying even if documented behavior). The question then becomes how is a user process to tell when the lock has become available again? Neither select(), nor poll() seem to have the desired affect. A couple possibilities that have floated by are to have a select() with a 30 second timeout, at which point scan the entire lock pending list. Are there any other possibilities? Also, could we get the fhopen, fhstat, and fhstatfs calls MFC-ed? They appear to be straightforward calls that do not depend on any VFS changes in -CURRENT. Furthermore they are very special purpose, they only have the potential to destabilize the system (if there are any bugs in them) if a program calls them. As it stands I know of zero production programs that would call these [nonexistent] syscalls :) -- David Cross | email: crossd@cs.rpi.edu Acting Lab Director | NYSLP: FREEBSD Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912190408.XAA45697>