Re: Behavior of flock() oriented procedures
- From: viza <tom.viza@xxxxxxxxx>
- Date: Mon, 2 Jun 2008 05:43:39 -0700 (PDT)
On Jun 2, 6:55 am, arcf...@xxxxxxxxxxx (Aaron Hsu) wrote:
Jens Thoms Toerring <j...@xxxxxxxxxxx> wrote:
I am trying to add an additional feature to Scheme's normal procedures
of OPEN-INPUT-FILE and family of CALL-WITH and WITH- procedures which
deal with files. The input/output datatype in Scheme is a port, but
unfortunately, a port does not explicitly have a unique file descriptor
available to implementations. I could use a file descriptor to make a
generic port on some Scheme implementations, but this isn't very nice
because it bypasses the native file ports support on implementations
that have faster file ports.
If indeed I need to save the file descriptor to use it later, then I
think I have no choice but to return a file lock object which later is
used to "unlock" the object. This will unfortunately create two
connections to the file, and make for some nasty interactions if we are
cose to the maximum limit of opened files. I have run into this before,
so I know it can be a problem.
The types of locking I have used are:
fcntl, lockf - no good because the lock is lost when you close *any*
descriptor for the file.
flock - the lock is lost when you close *all* descriptors dup()ed from
the one you obtained it for.
dotlock (to lock /file create /file.lock) - persistent but slow -
also if your program gets killed the lock remains forever, also, some
programs ignore dotlocks that they *guess* are stale.
cclient - (similar to dotlock, but create /tmp/.dev#.ino# and then
flock it) - more or less like dotlock but used where you might not
have write permission in the directories where you want to lock files.
So if you want persistent locking you need to use a file system based
one like dotlock - but these don't work if O_EXCL doesn't work, and
are slower.
If you are only trying to lock files so that other copies of your own
program don't mess with them, then it might be best to implement your
own locking method.
Regarding your point about too many open files, does it help if your
"lock object" is a dup()ed descriptor rather than an open()ed one?
viza
.
- Follow-Ups:
- Re: Behavior of flock() oriented procedures
- From: Marcel Bruinsma
- Re: Behavior of flock() oriented procedures
- References:
- Behavior of flock() oriented procedures
- From: Aaron Hsu
- Re: Behavior of flock() oriented procedures
- From: Jens Thoms Toerring
- Re: Behavior of flock() oriented procedures
- From: Aaron Hsu
- Behavior of flock() oriented procedures
- Prev by Date: Re: Behavior of flock() oriented procedures
- Next by Date: Re: aio_read/write versus O_NONBLOCK
- Previous by thread: Re: Behavior of flock() oriented procedures
- Next by thread: Re: Behavior of flock() oriented procedures
- Index(es):
Relevant Pages
|
|