On Tue, Sep 26, 2006 at 12:25:38PM -0400, Denis Papathanasiou wrote:
> >The lockfile wants an fd, which, AFAIK, only exists AFTER you open the
> >file.
>
> Ah, thanks for that clarification.
>
> You're right: I went back over the details of how file descriptors are
> created by the OS, and they're *temporary* non-negative integers based
> on what's available, given other file handles currently open, and the
> system's OPEN_MAX value -- so there's no way to correlate a pathname
> or a pathname namestring to a particular file handler.
>
> >So you have to open the file in Lisp too, via, with-open-file or
> >open or whatever. This will produce a fd-stream object and then you can
> >use sys:fd-stream-fd to get the fd associated with that file.
>
> I found it simpler to write a wrapper function in C around the fcntl()
> call: the wrapper takes the file name string, tries to create the fd
> then and there, and if it's successful, sets/removes the lock.
Note that, in Linux at least, and probably other Unix-esque operating
systems, closing the file descriptor releases the lock. If you don't
close the file, do you return the file descriptor so you can close it
later?
> Logically, it's probably no different to use (with-open-file), get the
> fd from (sys:fd-stream-fd) and call fcntl() with that fd as you
> suggested, but this interface seems simpler and cleaner to me.
If you're not reading/writing the file (via with-open-file or open or
whatever) then why lock it? If you *are* reading/writing the file,
why not use that file descriptor?
Your description makes me think you've implemented an interface
conceptually similar to this:
(defun lock (fname)
(let ((fd (open ...)))
(when fd
(fcntl fd LOCK))))
(defun unlock (fname)
(let ((fd (open ...)))
(when fd
(fcntl fd UNLOCK))))
and that just won't work.
-- L
