bogofilter over NFS

[Piotr KUCHARSKI]

On Sun, Feb 09, 2003 at 11:54:36PM +0100, Matthias Andree wrote:
> Regretfully, EAGAIN isn't very distinctive; it can mean "the lock you
> requested is held by another process" (which is kind of temporary) or it
> can mean "you must not lock this file because it's mmap()ed" (which is
> permanent), so we just need to try at run time and see what works. OTOH,

We could try to first lock database, then open it and when this
fails [mmap() will fail if file is fcntl()ed in scenarios where
fcntl() fails because of file being mmap()ed], try db_open again
without mmap. In this case we know fcntl() is alone and EAGAIN
means someone's else lock and we can loop over fcntl() quite safely,
while having possibility to reopen database, if it fails with
mmap due to being fcntl() locked.

> Thanks for the detailed analysis.
> exec 3>&- would be the proper magic.  

Oh. Have to remember that exec.

> The change you suggest is not robust enough IMO; 

Most probably. :)

> I moved the redirection into the VALGRIND variable itself:

I saw already. And really don't quite know why it hasn't been
possible to do valgrind >vg.out itself

> While this leaves room for further changes
> (--logfile=${TMPDIR}/vg.out), but I'll leave it this way for "maintainer
> efficiency" (a. k. a. laziness), it's equivalent and works.

Ah, laziness. That explains. ;)

> BTW, you cannot have valgrind because that's a tool that only works on
> ix86 based Linux currently. You may have heard of the commercial Purify
> tool; valgrind has similar goals.

Purify, sure. Why in make check, then? Hm.

p.

-- 
Beware of he who would deny you access to information, for in his
heart he dreams himself your master.   -- Commissioner Pravin Lal
http://nerdquiz.sgh.waw.pl/  -- polska wersja quizu dla nerdów ;)