From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net From: "Mathieu L." Date: Thu, 10 Sep 2009 11:51:52 +0200 In-Reply-To: <0224fcf7437ae954977afd3a2a53bdec@quanstro.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-cmxhfphquvsfqasghqduxyqkoj" Subject: Re: [9fans] dial and time out Topicbox-Message-UUID: 6ca0f650-ead5-11e9-9d60-3106f5b1d025 This is a multi-part message in MIME format. --upas-cmxhfphquvsfqasghqduxyqkoj Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit it seemed safer at first if I didn't have to worry about the procs preempting each other (and appart from that dial() bottleneck, I don't need them to), that's why I started with threads. I was thinking of sticking to threads and not using procs until I really do need them. But yeah, no real good reason not to switch to procs if that's the best way to go in that case. Mathieu. --upas-cmxhfphquvsfqasghqduxyqkoj Content-Type: message/rfc822 Content-Disposition: inline Return-Path: X-Original-To: lejatorn@smgl.fr.eu.org Delivered-To: lejatorn@smgl.fr.eu.org Received: by serenity.smgl.fr.eu.org (Postfix, from userid 58) id 195F07E82D; Thu, 10 Sep 2009 11:38:57 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on serenity.smgl.fr.eu.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by serenity.smgl.fr.eu.org (Postfix) with ESMTP id 4D8E27E82A for ; Thu, 10 Sep 2009 11:38:55 +0200 (CEST) Received: by bwz7 with SMTP id 7so1586980bwz.11 for ; Thu, 10 Sep 2009 02:38:54 -0700 (PDT) Received: by 10.204.11.18 with SMTP id r18mr746550bkr.15.1252575534032; Thu, 10 Sep 2009 02:38:54 -0700 (PDT) X-Forwarded-To: lejatorn@smgl.fr.eu.org X-Forwarded-For: lejatorn@gmail.com lejatorn@smgl.fr.eu.org Delivered-To: lejatorn@gmail.com Received: by 10.204.101.133 with SMTP id c5cs13811bko; Thu, 10 Sep 2009 02:38:53 -0700 (PDT) Received: by 10.101.48.2 with SMTP id a2mr1294085ank.175.1252575532394; Thu, 10 Sep 2009 02:38:52 -0700 (PDT) Received: from gouda.swtch.com (gouda.swtch.com [67.207.142.3]) by mx.google.com with ESMTP id 30si1303680iwn.19.2009.09.10.02.38.51; Thu, 10 Sep 2009 02:38:52 -0700 (PDT) Received-SPF: pass (google.com: domain of 9fans-bounces+lejatorn=gmail.com@9fans.net designates 67.207.142.3 as permitted sender) client-ip=67.207.142.3; Authentication-Results: mx.google.com; spf=pass (google.com: domain of 9fans-bounces+lejatorn=gmail.com@9fans.net designates 67.207.142.3 as permitted sender) smtp.mail=9fans-bounces+lejatorn=gmail.com@9fans.net Received: from localhost ([127.0.0.1] helo=gouda.swtch.com) by gouda.swtch.com with esmtp (Exim 4.69) (envelope-from <9fans-bounces@9fans.net>) id 1Mlg3N-0001JE-9X; Thu, 10 Sep 2009 09:34:57 +0000 Received: from ladd.quanstro.net ([69.55.170.73]) by gouda.swtch.com with esmtp (Exim 4.69) (envelope-from ) id 1Mlg3L-0001J8-A7 for 9fans@9fans.net; Thu, 10 Sep 2009 09:34:55 +0000 Message-ID: <0224fcf7437ae954977afd3a2a53bdec@quanstro.net> From: erik quanstrom Date: Thu, 10 Sep 2009 05:34:54 -0400 To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] dial and time out X-BeenThere: 9fans@9fans.net X-Mailman-Version: 2.1.10 Precedence: list Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.9fans.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces@9fans.net Errors-To: 9fans-bounces+lejatorn=gmail.com@9fans.net > I have a bunch of threads, simply scheduled with yield() at the moment > (I'll use alt later on), and each of them is calling dial() at some > point. I don't want the other threads to wait for "too long" when one > of them is blocked on a dial() that will eventually time out. > So I was thinking, for each of them, of creating a proc which would > be used as a timer; it would be created just before the call to dial, > wait for some time, and then kill the dial()ing thread. And as mechiel > suggested, the dial()ing thread would also be set to kill the timer > after it successfully dialed, hence not being killed if it was fast > enough. what's the reason for not using procs? - erik --upas-cmxhfphquvsfqasghqduxyqkoj--