Re: [Nmh-workers] dot locking broken?

[David Levine]

Marcin Cieslak wrote:

> >> David Levine <address@hidden> wrote:
> > Marcin wrote:
> >
> >> >> David Levine <address@hidden> wrote:
> >> >> >> I was also wondering if we should give the user to abort
> >> >> >> waiting for a lock with ^C.
> >> >> >
> >> >> > I tried, and ^C works for me (on Linux).
> >> >>
> >> >> That's interesting, from what I see in the inc code SIGINT is
> >> >> trapped in inc.c, lines 513++ ?
> >> >
> >> > And that code is conditional on trnflag.  I was testing with
> >> > -file, which didn't use it.  It looks like the signal handlers
> >> > are there to avoid corruption when the mailbox would be
> >> > modified.  I think they should be retained.
> >>
> >> Before we successfuly lock I think we cannot corrupt anything, so
> >> my idea to improve this is something along the lines below.
> >
> > The potential corruption problem is after locking.  Is it possible
> > to move the signal handlers to just after the lock is acquired?
>
> Maybe we could, I don't know... it leaves of course the possibility
> of having lockfiles left if interrupted.

Good point.

At this point, I think it's best to leave the code as is.  It avoids
corruption and orphaned lockfiles.  The downside is that the user has
to unnecessarily wait when the lock can't be acquired due to bad
configuration.  I don't think it's worth adding complex code to
alleviate that.

> I've had a brief look at lkfopen* invocations:
>
> context_save disables signals outside of lkfopen...lkfclose

Good.

> seq_save disables signals inside
> find_cache* do not disable signals
> get_msgnums() does not disable signals
> annotate() does not disable signals
> mbx_open() and its callers does not disable signals
> suppress_duplicates() does not disable signals

Offhand, I think those are all less important, but I might be
wrong.

> Btw. I think we can reduce files where <h/signals.h> needs to be
> included.

Done, thanks.

David