David Levine <levinedl(_at_)acm(_dot_)org> wrote:
Marcin wrote:
David Levine <levinedl(_at_)acm(_dot_)org> 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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers