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: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
