Re: [Nmh-workers] dot locking broken?

[Marcin Cieslak]

>> 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.

I've had a brief look at lkfopen* invocations:

context_save disables signals outside of lkfopen...lkfclose
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

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

> I'm not convinced that setjmp/longjmp is necessary here.

If we want to do it inside of the locking function,
I think it's the only way? But you are right, if we
do it outside after locking, then it is not necessary.

//Marcin