Re: [htdig-dev] Help required with "configure" - Porting Adjustable Logging Patch to 3.2

[Brian W. <bw...@st...>]

At 12:46 12/09/2002, Geoff Hutchison wrote:
>On Thu, 12 Sep 2002, Brian White wrote:
>
> > the "Yes" and "No" responses as expected ) but I have
> > no idea how to propogate my AC_DEFINE down to the
> > C++ code.
>
>Run "autoheader" and it will update the include/htconfig.h.in , which
>becomes htconfig.h which is #included in the code. You should get your
>DEFINE set, and then you can #ifdef, #ifndef, etc.

Cool. That worked.

> > Are there any problems with doing this? Are there
> > any conventions I should be following that I am not?
>
>Personally, if I don't have a system-level file-locking system, I'd
>implement one in user code, say with a .lock file in the same directory
>(if writable) or using TMPDIR and something like
>
>$TMPDIR/path-to-file.lock
>
>for locking /path/to/file.
>
>I've actually felt this might not be a bad addition to the htdig code
>anyway, since the databases really should be locked against multi-write
>until they have granularity.
>
>Does that make any sense?

Well, all except the "until they have granularity" bit -
what does that mean?

Well, I can write something for this if you like.

Issues include

1) What do we do about "dangling" locks? ( where
    lock files get left behind due to a crash or some
    other kind of bug)

    Do it specify a timeout time ( which requires accurate
    clocks if it has to work across machines ) and how is
    it specified? Or could we use unix PIDs ( which only
    work

2) If locks have to be valid across machines, the
    TMPDIR isn't going to work unless it is explicitly
    put into a common area?

3) Also - do locks need to work between different
    programs? What if they have different
    permissions - how do we

The more I think about it, actually, the more I think
using TMPDIR is a bad idea. Anything that needs to create
a lock which matters is going to be doing it for a write
file, which generally will give them write access to
the directory.

Either that or locks ALWAYS go in TMPDIR ( which still leaves
you with issue 2)

Brian








    One solution is to specify a timeout of some kind - though
    that kind of depends on being confident that that all process
    that use the lockfile have the same time reference, whether
    that is becasue they all run on the same machine, or they
    run on machines that are at least close to all having the
    same time.

    Another solution is to use the process id - but that
    only works on unix, and you either need to be running
    on the same machine or have the ability to access the
    other machines process list. There is also the lurking
    danger caused by the fact the PID's are recycled.

    Any thoughts?

2) Writing to TMPDIR will probably only work for
    processes running on the same machine.









>-Geoff

-------------------------
Brian White
Step Two Designs Pty Ltd
Knowledge Management Consultancy, SGML & XML
Phone: +612-93197901
Web:   http://www.steptwo.com.au/
Email: bw...@st...

Content Management Requirements Toolkit
112 CMS requirements, ready to cut-and-paste