>> David Levine <[email protected]> wrote: > Marcin wrote: > >> >> David Levine <[email protected]> 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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
