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]
