Actually, in the FileLock API it states <p> On some systems, closing a channel releases all locks held by the Java * virtual machine on the underlying file regardless of whether the locks were * acquired via that channel or via another channel open on the same file. It * is strongly recommended that, within a program, a unique channel be used to * acquire all locks on any given file. *
so it would appear that it is possible for the JVM to use fctl -----Original Message----- >From: Robert Engels <[EMAIL PROTECTED]> >Sent: Jan 24, 2007 10:19 AM >To: java-dev@lucene.apache.org >Subject: Re: [jira] Commented: (LUCENE-710) Implement > >Where do you see that the some JVMs map to fcntl, from what I can see they map >to flock? > >-----Original Message----- >>From: Marvin Humphrey <[EMAIL PROTECTED]> >>Sent: Jan 24, 2007 10:11 AM >>To: java-dev@lucene.apache.org >>Subject: Re: [jira] Commented: (LUCENE-710) Implement >> >> >>On Jan 24, 2007, at 8:04 AM, Robert Engels wrote: >> >>> Curious, I guess I don't understand the BSD disclaimer. The >>> application should not need to track any of this. The OS should be >>> tracking open FD and locks for the process, and when it closes a FD >>> on behalf of a process it should also remove the locks. >> >>You're right. A less aggressively truncated excerpt should make >>things clear. Here's the whole paragraph: >> >> This interface follows the completely stupid semantics of >>System V and >> IEEE Std 1003.1-1988 (``POSIX.1'') that require that all locks >>associated >> with a file for a given process are removed when any file >>descriptor for >> that file is closed by that process. This semantic means that >>applica- >> tions must be aware of any files that a subroutine library may >>access. >> For example if an application for updating the password file >>locks the >> password file database while making the update, and then calls >> getpwname(3) to retrieve a record, the lock will be lost because >> getpwname(3) opens, reads, and closes the password database. >>The data- >> base close will release all locks that the process has >>associated with >> the database, even if the library routine never requested a >>lock on the >> database. Another minor semantic problem with this interface >>is that >> locks are not inherited by a child process created using the >>fork(2) >> function. The flock(2) interface has much more rational last >>close >> semantics and allows locks to be inherited by child processes. >>Flock(2) >> is recommended for applications that want to ensure the >>integrity of >> their locks when using library routines or wish to pass locks >>to their >> children. Note that flock(2) and fcntl(2) locks may be safely >>used con- >> currently. >> >>Marvin Humphrey >>Rectangular Research >>http://www.rectangular.com/ >> >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> > > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
