Re: Can periodic hook stop rescheduling?

Re: Can periodic hook stop rescheduling?

[Bart Schaefer]

[>workers]

On Sep 13,  2:20pm, Peter Stephenson wrote:
} Subject: Re: Can periodic hook stop rescheduling?
}
} 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.
} 
} 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.

I suspect that what's happening is that the interrupt arrives during
the user input loop such that errflag is already set before the sched
function even begins running; and it therefore stops immediately on
entry without executing any actual commands.

Unfortunately it's a race condition so it's difficult to test/prove
this hypothesis.  However, there's pretty minimal testing of errflag
in preprompt() and none at all in cacl_timeout() so it might suffice
to check errflag and if set then defer the sched processing until the
next opportunity.  There would still be a race possible, but the window
would be much smaller.

The other (not mutually exclusive) option would be to make recurring
schedules part of the "sched" builtin itself, so that if a recurrent
event were interrupted it would nevertheless be rescheduled for the
next interval.

Neither of these is going to help Sebastian with 5.2-and-earlier.

Re: Can periodic hook stop rescheduling?

[Peter Stephenson]

On Tue, 13 Sep 2016 09:18:22 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> I suspect that what's happening is that the interrupt arrives during
> the user input loop such that errflag is already set before the sched
> function even begins running; and it therefore stops immediately on
> entry without executing any actual commands.

That's possible and we possibly need more sand in the box for that
case.  Some places are protected about an irrelevant errflag from the
environment, but timed functions in zle aren't, I don't think.

> The other (not mutually exclusive) option would be to make recurring
> schedules part of the "sched" builtin itself, so that if a recurrent
> event were interrupted it would nevertheless be rescheduled for the
> next interval.

I was thinking of that and sounds like a useful feature anyway.

pws

Re: Can periodic hook stop rescheduling?

[Bart Schaefer]

On Sep 14,  8:04pm, Peter Stephenson wrote:
} Subject: Re: Can periodic hook stop rescheduling?
}
} On Tue, 13 Sep 2016 09:18:22 -0700
} Bart Schaefer <schaefer@brasslantern.com> wrote:
} > The other (not mutually exclusive) option would be to make recurring
} > schedules part of the "sched" builtin itself
} 
} I was thinking of that and sounds like a useful feature anyway.

Yes, the danger is in scheduling something harmful and for a short
interval and then not being able to turn it off.

Re: Can periodic hook stop rescheduling?

[Sebastian Gniazdowski]

On 15 September 2016 at 06:51, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Sep 14,  8:04pm, Peter Stephenson wrote:
> } Subject: Re: Can periodic hook stop rescheduling?
> }
> } On Tue, 13 Sep 2016 09:18:22 -0700
> } Bart Schaefer <schaefer@brasslantern.com> wrote:
> } > The other (not mutually exclusive) option would be to make recurring
> } > schedules part of the "sched" builtin itself
> }
> } I was thinking of that and sounds like a useful feature anyway.
>
> Yes, the danger is in scheduling something harmful and for a short
> interval and then not being able to turn it off.

This might be a general topic of descheduling, its not-full
convenience. It is done via: sched -item (number of item on sched's
list as man page says). Apparently one has to fork, parse `sched`
output, establish item nr and invoke sched -item. Race condition isn't
possible because when being in function, then not being at idle
prompt, so sched won't be invoked and no deschedule will occur.
However these steps are not very convenient. Forgetting for a moment
about implementation effort, what would be the best is IMO a builtin
schedid that would put an ID (new kind, not the "item") of last
scheduled item into REPLY. No fork, no moving parts (i.e. no change of
entries' positions in the time ordered schedule list), a
hash-table-key-like ID, that a bigger script would be able to save for
use after say 2 hours when user would e.g. "unload plugin" (whatever
this means currently). As for the mistake schedule with short
interval, then maybe – that's not that best for me as schedid – new
builtin ksched, i.e. kill-sched, to deschedule all entries. I've seen
sched's code and it's really basic what's really cool, except maybe
for the around-precmd code when it get's run, I didn't see that. But a
new builtin is rather a unpleasant thing, one has to fill some
registration tables probably? What are chances for schedid, ksched,
automatic rescheduling? Maybe I could implement them when given green
light, however I first need to finish one plugin.

PS. Maybe instead of ksched – schedpop. Removes top entry from the
list. In case of problems with short interval and problematic
scheduled code, one would have to manage to enter schedpop few times,
in many cases single time.

PS2. About my question on periodic hook, is it immune to Ctrl-C?

Best regards,
Sebastian Gniazdowski

Re: Can periodic hook stop rescheduling?

[Bart Schaefer]

On Sep 15, 12:18pm, Sebastian Gniazdowski wrote:
} 
} This might be a general topic of descheduling, its not-full
} convenience. It is done via: sched -item (number of item on sched's
} list as man page says). Apparently one has to fork, parse `sched`
} output, establish item nr and invoke sched -item.

Well, sched was intended as a purely interactive feature since it
only works at all in interactive shells, so the assumption at the
time was that a human would read the sched output and remove the
corresponding item.  Hiding the scheduled tasks behind some kind
of UI and manipulating them programatically was not in the plan.

At the moment it's like you're complaining that it's inconvenient
that your 1989 Volvo doesn't have keyless ignition.

} new builtin is rather a unpleasant thing, one has to fill some
} registration tables probably? What are chances for schedid, ksched,
} automatic rescheduling? Maybe I could implement them

They're more likely to show up as options to "sched" itself than as
new separate builtins.

} PS2. About my question on periodic hook, is it immune to Ctrl-C?

It's not immune in the sense that you can interrupt the function
while it's running, but it is immune in that it keeps repeating as
long as PERIOD has a value even if it was interrupted last time.