Zsh Mailing List Archive
Messages sorted by:
Re: Can periodic hook stop rescheduling?
- X-seq: zsh-workers 39308
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: Can periodic hook stop rescheduling?
- Date: Tue, 13 Sep 2016 09:18:22 -0700
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=+nI9tHgbBJr8z8fUhHeszum++gzLkMKxFE8Ph7AOXh4=; b=UUKO1N0LUga6/JnOlJKtP3q6KaWSzmVlYu0cF6o4uupnB8nBWxL+xBQtNlS4hVH5FH +W76d9mWcePRuSuT5hNfrt+hfB/iXDXM+QNqxx3TTRnKGNSTIXI3R/QUmq0KF27qvGOx 6PbLX70mYyKVh/Ib0cWoVoMN/YrOrjQq+oowYmHvyQt2x4cnkxIUE4ZLJZE7uZDbZjCH igEdxsdXTc+PHXVHz171S6H8RCn73J6qAmtedVtJ4hQCHDpO1OwuJyuEHapu5BtUTN7g 4bntPQmx2OhW6t6qmdG5BvTkn8N5A3Zs13N8ZFp+cOVLKM+XKpd1o6FEJbqwQt2uJ2/b nqhA==
- In-reply-to: <firstname.lastname@example.org>
- List-help: <mailto:email@example.com>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <CGME20160913085130eucas1p19723ac09c11d596542360173e4a4b308@eucas1p1.samsung.com> <CAKc7PVDkrKD_2VyvO_2JigwfvU1m=3QwO4Vac=HgHZNbOOU7pA@mail.gmail.com> <email@example.com>
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@xxxxxxxxx> 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
Neither of these is going to help Sebastian with 5.2-and-earlier.
Messages sorted by: