From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3883 invoked by alias); 13 Sep 2016 16:18:19 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 39308 Received: (qmail 16060 invoked from network); 13 Sep 2016 16:18:19 -0000 X-Qmail-Scanner-Diagnostics: from mail-pf0-f176.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.192.176):SA:0(0.0/5.0):. Processed in 0.724057 secs); 13 Sep 2016 16:18:19 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts) 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== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=+nI9tHgbBJr8z8fUhHeszum++gzLkMKxFE8Ph7AOXh4=; b=ERbLXGkITcQ6PIYXuZ98i58ZyyDkrLgY/tGK6doqNz6WX3gAeqOhTSNk2dJtF8Op6Z i600rXSy+qSrL3B+12JeWG2VFAMeVVrr1gWYXjpNTL5fjV/mZQP5EGfxW7F8PrlJoXAW 9NgDy4MNgUMeifSHyjbz2DvQ1IeExgrcBAD8pwJ6bsjCXVlnEApyKr6XXSZyYthkrCfO FS0WbyfsfIDlrdMlVOH/Qn+KGE6G41qA8xEld42r5n9r4naJgG+qBV4JPfo1kH2A4v1V jnzbwWasoDDPIa0oPrmMOJcJkM2X0tBMs470L1t5BPavyqoFLCSGDPdNuRTzbMbQ/ugd /Igw== X-Gm-Message-State: AE9vXwORaxEEp0FxWHs63LEfq2R/FF7S29zxXdIa8ckKXqIXP8tmZVvMYlRM6AUJgu9LyQ== X-Received: by 10.98.147.202 with SMTP id r71mr2785036pfk.34.1473783492291; Tue, 13 Sep 2016 09:18:12 -0700 (PDT) From: Bart Schaefer Message-Id: <160913091822.ZM29020@torch.brasslantern.com> Date: Tue, 13 Sep 2016 09:18:22 -0700 In-Reply-To: <20160913142003.480cfd9c@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: Can periodic hook stop rescheduling?" (Sep 13, 2:20pm) References: <20160913142003.480cfd9c@pwslap01u.europe.root.pri> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Can periodic hook stop rescheduling? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii [>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 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.