On Sep 13, 2006, at 16:51, Marcus Watts wrote:
Robert Banz <[EMAIL PROTECTED]> writes:
...
Here's my take on the lockf stuff switching to fcntl locking... Only
bothered to emulate F_LOCK & F_ULOCK because, well, that's all
namei_ops uses. I've tested it on sunx86_510, it seems to be doing
it's thing.
...
+ #define lockf(a,b,c) fcntl_lockf_emulator(a,b,c)
+ int fcntl_lockf_emulator ( int fd, int function, off_t size ) {
...
+ return fcntl( fd, op, &fl );
Uhhhh. I think you've just recreated the "flock.o" that's in libc,
+/-
naming & feature support. Have you tried it in conjunction with
close()? I believe you'll find that fcntl locking has exactly the
same
behavior as lockf, insofar as its interaction with close() goes.
Yeah, it's pretty much flock(), but for testing/development it was
easier to do something like this than 'fix' the handful of places
that lockf() is currently in use. But it sets the beginning of the
lock to '0' without seek()ing around to do it, which is probably a
good thing.
WRT the close problem... I've read Tom's post on the subject, and,
it's potentially an issue, but from what I see it's really a separate
problem than the seek-position-caused one... Now, the question is
how to go about dealing with it? Yuk, it's making my brain melt.
-rob
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
