Can periodic hook stop rescheduling?

Can periodic hook stop rescheduling?

[Sebastian Gniazdowski]

Hello,
I'm using sched to call a function. The problem is, it sometimes
doesn't reschedule. sched +2 is the first line of the scheduled
function, however I observed, that when running a completion and
pressing Ctrl-C to abort something in it (when using
:completion:*:*:*:default' menu yes select search) this Ctrl-C might
somehow apparently reach scheduled function and block reschedule. I've
added a protection via preexec hook – I check when scheduled function
did last run and reschedule when a delay is detected.

I thought about adding such protection via periodic hook. The question
is: is it fully robust? Doc says that error in precmd will stop
periodic function, however it isn't clear about next expected run of
it:

"Note further that an error in a precmd hook causes an immediately
following periodic function not to run (though it may run at the next
opportunity). "

So, is the reschedule of periodic fully robust, or is it possible that
error in precmd (and maybe Ctrl-C press) will block reschedule?
(blocking single run is fine)

Best regards,
Sebastian Gniazdowski

Re: Can periodic hook stop rescheduling?

[Peter Stephenson]

On Tue, 13 Sep 2016 10:49:35 +0200
Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote:
> I'm using sched to call a function. The problem is, it sometimes
> doesn't reschedule. sched +2 is the first line of the scheduled
> function, however I observed, that when running a completion and
> pressing Ctrl-C to abort something in it (when using
> :completion:*:*:*:default' menu yes select search) this Ctrl-C might
> somehow apparently reach scheduled function and block reschedule. I've
> added a protection via preexec hook – I check when scheduled function
> did last run and reschedule when a delay is detected.

The function that's being called is certainly not immune from getting
^C, and that can certainly stop "sched +2" in its tracks just like any
other command.  The only general fix for this would be blocking SIGINT
sufficiently early that ^C doesn't hit this and restoring it later ---
but given sched +2 is the first line of the script anyway that doesn't
look promising.

You might have better results with

  {
    ...
  } always {
    sched +2 ...
  }

but it's still subject to the same problem if the ^C happens at the
wrong point.

This may need some lateral thinking.

pws

Re: Can periodic hook stop rescheduling?

[Sebastian Gniazdowski]

On 13 September 2016 at 15:20, Peter Stephenson
<p.stephenson@samsung.com> wrote:
> On Tue, 13 Sep 2016 10:49:35 +0200
> The function that's being called is certainly not immune from getting
> ^C, and that can certainly stop "sched +2" in its tracks just like any
> other command.  The only general fix for this would be blocking SIGINT
> sufficiently early that ^C doesn't hit this and restoring it later ---
> but given sched +2 is the first line of the script anyway that doesn't
> look promising.

Blocking INT is the second thing done in the function:

    setopt localtraps; trap '' INT

I thought: sched will run faster than "setopt localtraps..." and this
way give better guarantee that rescheduling will not be stopped. So I
chosen to sched first, then block trap, but can reverse that, no
problem.

> You might have better results with
>
>   {
>     ...
>   } always {
>     sched +2 ...
>   }
>
> but it's still subject to the same problem if the ^C happens at the
> wrong point.
>
> This may need some lateral thinking.

"always" looked promising, too bad it's still subject to Ctrl-C

Best regards,
Sebastian Gniazdowski