From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15896 invoked by alias); 19 Jun 2017 15:30:40 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 22736 Received: (qmail 14123 invoked from network); 19 Jun 2017 15:30:40 -0000 X-Qmail-Scanner-Diagnostics: from mail-vk0-f54.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.213.54):SA:0(-0.0/5.0):. Processed in 2.247853 secs); 19 Jun 2017 15:30:40 -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=RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS,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: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.213.54 as permitted sender) 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=wi4e2NQwQ0dZAswLQ4tduuJAI+C22UuAB2Jr2ox9KrM=; b=aKd5GgdEZ00tyhcyfBDV5PEPyHjLcN4s1vHmwyswxnLT0wghhE6YbpBccniMxWPKz7 IFemp1SC8SWG4FfY4m6qRFKMj7dc3TPsmtCC1kn5Bjzowwn2DytrPFRRVHgVZz4fzQUK WyPPs3Q3xzGI9axy2R8Rrc5BR/nisvX4OHPKcC1YZZpHMOSynPRTpUaAdWV42SdU7Hr7 VxayQnw9IizOswof5BfIvXr+hKgY8ltR3wlBRlvW1KkFkALTwnex/M3FWR9vli12+14V 99+yIN/gHkwOKWySTRSeaV7Xal6z2ZjXxuPphsa9WibuAgsfAcYhgNhvwXPJGc/oNCrq af2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=wi4e2NQwQ0dZAswLQ4tduuJAI+C22UuAB2Jr2ox9KrM=; b=G96IhPzzMQGaHRJ5uTkGyuAXLkx67DEX9n9GBf27s6EyoDCFGmk/3oZEAJtL77dOzU v4t4rBD7rAQ2ua4xlTlG4tmePvEjnpIwHWrTElskddEWTAp9kph3pUyI8lPLWQgGHzwl JujnXC/IdOu5esc+zJAOILBTdQkydGpsNJGnJoU1z7QjeNOcAizewH/U/4qtask3TkeD VbUlDKSiRFdhPXOAzOmhjCeL+/YMoqfpJ60e55lFYIPQ5iYETToxff+n75N8EYNTU/Bo UrH++BHWQ9u0+99nvFFGFHejtijDREC7n9qyvqJ2daug63xUwt+lnoXq4iYnG2HMciqq mCvA== X-Gm-Message-State: AKS2vOwTdRbvOjkFPsngJdtuLkVIjYeiYD8UqpS7xVnuBbqUlXYtP72f kI82g+zqwYpuCKLsJfA= X-Received: by 10.31.157.2 with SMTP id g2mr12800848vke.60.1497886229120; Mon, 19 Jun 2017 08:30:29 -0700 (PDT) From: Bart Schaefer Message-Id: <170619083116.ZM17323@torch.brasslantern.com> Date: Mon, 19 Jun 2017 08:31:16 -0700 In-Reply-To: <20170619122413.GA9294@chaz.gmail.com> Comments: In reply to Stephane Chazelas "Re: Why sourcing a file is not faster than doing a loop with eval, zle -N" (Jun 19, 1:24pm) References: <20170619122413.GA9294@chaz.gmail.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: Why sourcing a file is not faster than doing a loop with eval, zle -N MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jun 19, 1:24pm, Stephane Chazelas wrote: } } There's probably scope for optimisation here, though I can't } comment further as I don't know why that signal handling code is } there in the first place. rt_signprocmask should not be significantly more expensive than an assignment to an integer. The signal handling code is there because the shell MUST NOT respond instantly to arbitrary signals while doing operations such as token interpretation or or memory management -- the signal handlers might themselves invoke shell commands/functions and many of those layers are not safe for re-entrancy -- but it MUST respond to those signals whenever it may be blocked for an unknown length of time, such as when reading from a file descriptor. Many years of "I can't interrupt my script when X" or "interrupting my script when Y causes a crash" resulted in the current signal paradigm. When the shell was first written, processors weren't fast enough and process scheduling not well-threaded enough to expose a lot of these issues, but the better our computers get the greater the likelyhood of hitting an ever-smaller race condition window, so those windows have to be aggressively closed.