filelock icon indicating copy to clipboard operation
filelock copied to clipboard

itimer state is not restored

Open lionel- opened this issue 1 year ago • 2 comments

Currently filelock restores the SIGALRM handler to its previous state but the itimer state is not restored.

lionel- avatar Mar 25 '23 10:03 lionel-

Hmmm, considering that there can be only one active timer, and we always remove the timer before returning, it does not seem like it is important to restore the old handler. Is there a case where this can cause problems?

OTOH it also does not seem to cause any issues if we restore it, so we might as well.

gaborcsardi avatar Mar 25 '23 11:03 gaborcsardi

There can only be one timer active at any time but if you restore the old signal handler it also makes sense to restore its timer interval. The handler will have missed some intervals but it should normally be written to account for this possibility since the timer interval is only a lower bound and the system might take longer to issue a signal.

In the case of real-time profiling in Rprof() using SIGALRM, restoring the handler along with its timer state allows to resume profiling as normal once the filelock routine has finished using the timer. This is not perfect and Tomas has plans to use a timer thread instead to avoid interactions with other alarm handlers, but hopefully we can still get this feature implemented with POSIX signals in the next version of R.

lionel- avatar Mar 25 '23 11:03 lionel-