spamassassin-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Justin Mason)
Subject Re: [ Fwd: Reminder: SpamAssassin needs your help!]
Date Sat, 03 Apr 2004 00:13:05 GMT
Hash: SHA1

Alexis Rosen writes:
>Hey, guys. I'm just following up because I'm curious about the final
>disposition of the nfslock code. Did you add a function to correspond to
>nfsunlock? I hope the rest of my comments were helpful.

Actually, we haven't :(   It dropped off my radar, unfortunately.

I'm thinking we should take a look at that before 3.0.0 release, and
probably we should also add a *non*-NFS-safe locking function too for
hosts where NFS is not involved -- as I think we could cut down
lock overhead quite a lot that way.  

- --j.

>On Fri, Oct 31, 2003 at 05:55:02PM -0500, Alexis Rosen said:
>> On Fri, Oct 31, 2003 at 10:29:12AM -0800, Justin Mason said:
>> > >That said, I've glanced at the code, and I see a couple of potential problems.
>> > >
>> > >I may be completely missing something here, but it looks like the lockfile
>> > >is uniqued by hostname. In that case, it's not locking anything, unless
>> > >have some other means of guaranteeing that the file being locked will never
>> > >be touched by more than one host.
>> > 
>> > I don't think so, at least -- the code is (as far as I can see):
>> > 
>> >   - generate random file we can always create: $path.lock.$hname.$$
>> Right. Sorry, I was just looking at it quickly. Too quickly...
>> However... I now remember thinking about using the hostname when I was
>> writing this. I decided that nfslock was already pretty expensive, and
>> that adding the hostname was really not an advantage.
>> > >There is also the tricky problem that you need to have a corresponding unlock
>> > >function or you run the risk of trashing locks you don't own. See comments
>> > >in my code for details... wait, you probably don't have it. I'll send it
>> > >to you shortly.
>> > 
>> > Interesting; we'd better check that.
>> OK, here's the source. It's attached (only ~10k). A few things to think about:
>> - Some of the issues involved are *really* subtle. Don't throw out the sleep
>> in nfsunlock, for example.
>> - The race condition that made me write nfsunlock may seem a virtual
>> impossibility, but if you are actually running across NFS, it's not the most
>> unlikely thing in the world. All you need is a small network problem at the
>> wrong time.
>> - nfs{,un}lock4 was written to deal with a bug in netbsd. It had a hideously
>> broken nfs client that didn't act atomically even for link(). Nothing you
>> can do about that except work around it as best you can. I encourage you to
>> NOT use this workaround- it's very expensive, and the problem no longer exists,
>> I think. nfstest is a tiny bit of code that can turn up systems with that
>> problem. I know of no other Unixes that have that problem.
>> Any other questions, just ask.
>> /a
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh CVS


View raw message