From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21267 invoked by alias); 22 Jan 2014 08:05:06 -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: 18345 Received: (qmail 27984 invoked from network); 22 Jan 2014 08:04:59 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 From: Bart Schaefer Message-id: <140122000435.ZM1516@torch.brasslantern.com> Date: Wed, 22 Jan 2014 00:04:35 -0800 In-reply-to: Comments: In reply to Arseny Tolmachev "[Feature suggestion] (user configurable) timeout for generating completion lists" (Jan 20, 4:13pm) References: X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: [Feature suggestion] (user configurable) timeout for generating completion lists MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Jan 20, 4:13pm, Arseny Tolmachev wrote: } } Sometimes you press [Tab] by instinct when in directory that is } network-mounted and has some millions files in it. } In this situation zsh basically ignores the [Ctrl+C] and don't respond to } anything for a bit of time. There are two possible situations here. (Probably more than two, but only two likely ones.) (1) The shell process is actually in "disk wait" condition, blocked to wait for the NFS volume to respond. If this is the case, there's not a lot that can be done; any timeout that might be set up will also be held until the disk condition clears. (2) The shell is chewing CPU cycles for a large amount of file data, but ignoring or deferring some signals while it does so. In this case there's some hope of a timeout working. It could also be switching back and forth between these two states ... but that can be treated as case (2) except that it might take longer for the timeout to work. } It would be very great if there was a way to specify a timeout for } completion generation for zsh. Error message can be something like } "completion timeouted". } What do you think about this? I've been poking at it for a couple of hours trying to repeatably induce case (2), and I can't get reliably force it to happen. It would be helpful if somebody who experiences this problem could attach to the stuck zsh with gdb and grab a stack trace. Note that in case (1) above, gdb is likely to end up wedged as well. Anyway, anything we could do for a timeout would likely require handling a signal, which pretty much means we're going to bail out of the shell functions (e.g., _main_complete and everything below it) that perform completion. I don't immediately see how to produce an error message in that case without messing up the ZLE display unless we also have a shell level trap handler (instead of a purely internal one). But in order to even get that far, we have to know what's holding things up.