From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 732 invoked by alias); 1 Sep 2018 19:12:43 -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: List-Unsubscribe: X-Seq: 43361 Received: (qmail 793 invoked by uid 1010); 1 Sep 2018 19:12:42 -0000 X-Qmail-Scanner-Diagnostics: from mail-oi0-f53.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.218.53):SA:0(-1.9/5.0):. Processed in 1.30065 secs); 01 Sep 2018 19:12:42 -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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS, T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: sgniazdowski@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=0749i+u8nElgrcpGAKrm7JkW8hhsUYpph3tugMBcY4I=; b=Y2XvfdU5FOD2RQwDs6Zsz87a8DOSE9011bhwXhcChxsn+lgq7KBsg8tctmxUt7R5Sl yxV2KjSDCpSkJeQbPS8ZQTYrg45mwuVGVcC6HVkxK4iUcvt+WihODG89a9dyZSQV7zIt p5chbaZXS5Ypq6KR2wXQQtNQZgO9NVqwsLGGhA+3GttijTVGVFFUe3ZBQL3Zz9kYm6qb ++0uiehnkHXQTlFf3RkGSgLeUy11fn6SEbyRF1d19Yg4zBYe2iHvVIHGE8LV8++9y/S5 XKJhmd7c2UBZsaq8f3NAX6Ly/C+2/pTe0UFpnBwTAjuAqfRA1dDHeADb2fJ5YkHEJlEH 2sjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=0749i+u8nElgrcpGAKrm7JkW8hhsUYpph3tugMBcY4I=; b=WPaxWK1KHvL4ZytQ33N6uK5zl2ND2nQ8hRCYpvvAFqGxpXPBQ0ylgWz/8JUU+xaxHt GVX+AfKgPYy864M645PPm6DRNNtGmM3Aadsd0l4wrTEKqzrJ9cXoFH7qFaJ/jBkeNh6Y iAgtBy9c/JchjU6ty/eL0T091M24iw1qVrQk7YxL53N7rWhkLLqc/JMpAbK89pAEo0j2 XXRqbUfd/heb9ir9kq/vRzNDyIgFHuTuRqNmaWLZRK/SV8Cile0wAbmqBX6BwwK4FhN3 CZeG4ZOeLmyj8f3L7w4uvTuj+ng51P8WP4Rf+xXqnzqz+tky6pFZ2m724UL9zdczz+Zc q7Bg== X-Gm-Message-State: APzg51DZt8zQoy1ZosLzNkn1yqwo92U/W/kd9sKMKIlFg42GRftxxaMi +tbgujsTzZXFVHBSvLBiB77cA1v/C5O3ja5EJFsXTRgE X-Google-Smtp-Source: ANB0VdbXWg+m7DGhhc/1PsQS6R2A8au/FvJXiVX97dHWRiGtA8Tm8Q+YVBmKrooQTmli4oyqVzLEkZxY5tgGKdoDuJ8= X-Received: by 2002:aca:494b:: with SMTP id w72-v6mr5188177oia.293.1535829158359; Sat, 01 Sep 2018 12:12:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sebastian Gniazdowski Date: Sat, 1 Sep 2018 21:12:26 +0200 Message-ID: Subject: Re: [BUG?] Very strange behavior, execution of a function is interrupted To: Zsh hackers list Content-Type: text/plain; charset="UTF-8" I've found the cause. `compinit' does `read -q' when occurring insecure directories. If this happens from `sched' with possibly Zle being active, then following call inside bin_read() uses Zle's raw_getbyte() to read a character: zleentry(ZLE_CMD_GET_KEY, izle_timeout, NULL, &val); This means that `read' can make all the rich side-effects of the regular command-line to activate. I think this has significant importance, is severe. I wouldn't expect the `read' builtin to bring up whole `zle -F' handling, waiting for inputs, invoking callbacks. Below test code confirms the above thesis. Its execution is recorded here: https://asciinema.org/a/199265 Basically, my problem is that Zplugin's scheduler gets invoked in nested manner because of compinit's `read -q' (I was doing stress tests with compaudit activating) and data structures go to improper state. FD=1337; setup() { exec {FD}< <( sleep 1; echo run ) zle -F $FD -my-scheduler echo "Sched call reporting being called" read -q "?[y/n]?" echo "Sched call reporting exiting" } -my-scheduler() { local THEFD="$1"; zle -F "$THEFD"; exec {THEFD}<&- # remove zle -F handler echo "Zle -F handler reporting being called" } sched +1 setup On Sat, 1 Sep 2018 at 00:01, Sebastian Gniazdowski wrote: > > Hello, > it's quite a lost game to explain this, but I'll try: > > - there is a scheduler called from sched +1 and once from zle -F > - it detects timed-out tasks, moves them to ZPLG_RUN, then executes > them reading them from this array > > Problem: sometimes execution never reaches this line and beyond: > https://github.com/zdharma/zplugin/blob/7a24478e5862a1359b6cfb2887a792213be07e3a/zplugin.zsh#L1485 > > Some cycles of the preceding loop are then also skipped. > > I feel very helpless in explaining this, maybe there's standard > questions sheet for situation where bug in exec.c is suspected? > > I know `break 2' inside a function will break out of loop that > contains the function call. But I don't know what could exit a > function. I have debug prints and observe this clearly. At the > mentioned line, no execution occurs, ZPLG_RUN isn't cleared, I get to > run some tasks twice. > > Twice when I checked, it was happening when zle -F was called so near > next second, that timeout'd tasks detection included two time slots: > "0" (0 seconds after first precmd, handled by zle -F) and "1" (1 > second after first precmd, handled by sched +1). > -- > Sebastian Gniazdowski > News: https://twitter.com/ZdharmaI > IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin > Blog: http://zdharma.org -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org