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