fcntl always fails to delete lock file, and PID is always -6464

[Daichi GOTO]

Next step discussion engaged from this research I guess.

Should we do change FreeBSD's fcntl(2) to return correct l_pid
when called with F_SETLK?  Or keep current behavior??
I want to hear other developers ideas and suggetions.

On Mon, 4 Oct 2010 20:17:08 -0700
Garrett Cooper <gcooper at FreeBSD.org> wrote:
> test_fcntl: fcntl: Resource temporarily unavailable
> PID=1 has the lock
> 
>     Huh...? init has the file locked...? WTF?!
>     So assuming Occam's Razor, I did a bit more reading and it turns
> out that l_pid is only populated when you call with F_GETLK:
> 
>      negative, l_start means end edge of the region.  >>> The l_pid and l_sysid
>      fields are only used with F_GETLK to return the process ID of the process
>      holding a blocking lock and the system ID of the system that owns that
>      process.  Locks created by the local system will have a system ID of
>      zero.  <<< After a successful F_GETLK request, the value of l_whence is
>      SEEK_SET.
> 
>     Thus, after fixing the test app I'm getting a sensical value:

-- 
Daichi GOTO
81-42-316-7945 | daichi at ongs.co.jp | http://www.ongs.co.jp
LinkedIn: http://linkedin.com/in/daichigoto