From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23348 invoked by alias); 14 Jun 2011 18:55:31 -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: 29480 Received: (qmail 24955 invoked from network); 14 Jun 2011 18:55:24 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) 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.1 Received-SPF: pass (ns1.primenet.com.au: SPF record at ntlworld.com designates 81.103.221.49 as permitted sender) Date: Tue, 14 Jun 2011 19:54:58 +0100 From: Peter Stephenson To: Subject: Re: killing suspended jobs makes zsh hang after 47d1215 Message-ID: <20110614195458.67af06e2@pws-pc.ntlworld.com> In-Reply-To: <110613073748.ZM2701@torch.brasslantern.com> References: <86aadnwtl2.fsf@gmail.com> <110612072211.ZM26399@torch.brasslantern.com> <110612075958.ZM27334@torch.brasslantern.com> <8662oaha3g.fsf@gmail.com> <110612185339.ZM28551@torch.brasslantern.com> <20110613120747.2f018471@pwslap01u.europe.root.pri> <110613073748.ZM2701@torch.brasslantern.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=JvdXmxIgLJv2/GthKqHpGJEEHukvLcvELVXUanXFreg= c=1 sm=0 a=QqggLpzxxH8A:10 a=uObrxnre4hsA:10 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=NLZqzBF-AAAA:8 a=Cg4EvQS_f-SPML6TYPYA:9 a=3u6ipyMuuR2y4ErohKIA:7 a=CjuIK1q_8ugA:10 a=I6wTmPyJxzYA:10 a=_dQi-Dcv4p4A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 On Mon, 13 Jun 2011 07:37:48 -0700 Bart Schaefer wrote: > In the 28965 case we might be able to fix it by having findproc() > continue to scan the table for running jobs any time it encounters > one that matches but is not running, as long as it eventually does > return the first one it found if there are no others. Possibly I'm being dozy but this is the first thing I've heard that sounds like a robust fix, if it's the case that we always find an appropriate running process in the case that was causing the original problem. I don't think efficiency is a problem. zsh makes no attempt to ensure the process you're actually looking for is found quickly in any case. If it is a problem, surely that means the process search is intrinsically inefficient and we need to do something more basic about it such as putting the processes in a hash table, or whatever. Generally, I suspect it's rare for the shell to have enough processes to make the time is important, and if it is important this change is a minor effect. Of course, if anyone wants to profile it they're welcome. -- Peter Stephenson Web page now at http://homepage.ntlworld.com/p.w.stephenson/