From owner-freebsd-arch@FreeBSD.ORG Mon Mar 31 14:21:06 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BC2037B401; Mon, 31 Mar 2003 14:21:06 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7619F43F75; Mon, 31 Mar 2003 14:21:05 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.9/8.12.9) with ESMTP id h2VMKvMS020892 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 31 Mar 2003 17:20:58 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h2VMKqk27630; Mon, 31 Mar 2003 17:20:52 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16008.48964.858472.638793@grasshopper.cs.duke.edu> Date: Mon, 31 Mar 2003 17:20:52 -0500 (EST) To: Julian Elischer In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: John Baldwin cc: freebsd-arch@FreeBSD.org Subject: RE: cv_timedwait() & exiting procs X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2003 22:21:08 -0000 Julian Elischer writes: > > Some comments to your thoughts.. It would be a valid thought to allow > the syscall to complete if the sleep completed. but why? Also, Maybe the > test should also test if we are: > > 1/ threading > and > 2/ not the thread that is actually DOING the exit() > (though exit doesn't do any sleeps that I KNOW of) That would be nice, if I understand what you're saying. The scenario that I'm in is that I have character driver. At certain points, we send "commands" to the the device and sleep on a cv. When the device completes the command, it interrupts the host and the interrupt handler does a cv_signal. If the device does not respond after some seconds, we consider the device dead. One of these commands is issued when the device is closed. The problem occurs when an application does not call close himself, rather he just exits, and our driver's close entry point is called from the exit() code path. The "command" associated with device closes is issued in the context of this (single threaded) process. All is well, and the device responds. The interrupt happens. cv_signal() is called. But: cv_timedwait() then returns with EWOULDBLOCK. Because EWOULDBLOCK is returned, the driver assumes the timeout has been exceeded and device has gone dead. Sure, this is easy enough for me to fix in the driver code, but it really makes FreeBSD's condvar interface look busted.. I was thinking that we could only return an error because of P_WEXIT being set if P_WEXIT was not set when the cv call was entered. Drew