From owner-freebsd-questions Wed Oct 30 20:16:51 2002 Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9665F37B401 for ; Wed, 30 Oct 2002 20:16:50 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E3C643E6E for ; Wed, 30 Oct 2002 20:16:50 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.3/8.12.5) with ESMTP id g9V4GigQ062978 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 30 Oct 2002 23:16:44 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.3/8.12.5/Submit) id g9V4GhqG062975; Wed, 30 Oct 2002 23:16:43 -0500 (EST) (envelope-from wollman) Date: Wed, 30 Oct 2002 23:16:43 -0500 (EST) From: Garrett Wollman Message-Id: <200210310416.g9V4GhqG062975@khavrinen.lcs.mit.edu> To: =?iso-8859-1?q?shubha=20mr?= Cc: freebsd-questions@FreeBSD.ORG Subject: untimeout reliable? In-Reply-To: <20021031040420.78826.qmail@web41112.mail.yahoo.com> References: <20021031040420.78826.qmail@web41112.mail.yahoo.com> Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG < said: > Simply put,will untimeout cause to de-establish a > timeout irrespective of the position/status of a > timeout already scheduled?In other words,will > untimeout prove futile sometimes? No and yes, respectively. If the timeout is already running, untimeout (or more properly, callout_stop()) cannot do anything about it. All it can do is remove the timeout from the list of things to be called next time. What this means for a developer is that you need to provide some other means of mutual exclusion, and you need to be very careful with timeout handlers that reestablish their own timeouts. (Such handlers will need a ``go away'' condition that they can check before rescheduling the timeout.) The old timeout()/untimeout() interface is deprecated, by the way. New applications should use callout_reset()/callout_stop() instead. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message