From owner-svn-src-projects@FreeBSD.ORG Tue Oct 15 19:48:01 2013 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B31CD402; Tue, 15 Oct 2013 19:48:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B5542371; Tue, 15 Oct 2013 19:48:01 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AD85EB962; Tue, 15 Oct 2013 15:48:00 -0400 (EDT) From: John Baldwin To: Alexander Motin Subject: Re: svn commit: r254846 - projects/camlock/sys/cddl/contrib/opensolaris/uts/common/fs/zfs Date: Tue, 15 Oct 2013 15:24:00 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201308251121.r7PBLA3v033536@svn.freebsd.org> <201308261425.34743.jhb@freebsd.org> <525CF9FC.2000109@FreeBSD.org> In-Reply-To: <525CF9FC.2000109@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201310151524.00731.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 15 Oct 2013 15:48:00 -0400 (EDT) Cc: svn-src-projects@freebsd.org, Adrian Chadd , "src-committers@freebsd.org" X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 19:48:01 -0000 On Tuesday, October 15, 2013 4:17:00 am Alexander Motin wrote: > On 26.08.2013 21:25, John Baldwin wrote: > > On Sunday, August 25, 2013 9:29:06 am Alexander Motin wrote: > >> On 25.08.2013 15:48, Adrian Chadd wrote: > >>> Surely there's a better way to check whether a thread can sleep besides > >>> digging around in curthread->td_no_sleeping ? What about adding an > >>> accessor macro along side THREAD_SLEEPING_OK and THREAD_NO_SLEEPING ? > >> > >> That sounds good to me. I was also surprised such macros are not there > >> yet when found some code doing these checks just the same way as I did. > > > > It was never intended to be public, only as a debugging aid for assertions. :( > > I had hoped that the calling code would know when it was in an ithread or not > > and call different routines as needed (i.e. that the programmer would > > intentionally think about the context they were in). Perhaps this is not > > realistic? Are you really queueing new I/O from ithreads and/or timers? > > I've found potential case where it is not realistic. Requests are > normally completed from the interrupt threads. Completion caller does > know that it is impossible to sleep in that context. But it holds no > locks, it is re-enterable, and so it allows direct completion. Request > goes up the stack and at some point on the call chain this completion > triggers another request to be sent down (may be even to some different > device), but again directly. This new request sender knows nothing about > interrupt context and the fact it can't sleep. > > Can you propose some other way to deal with such case other then using > per-thread flag/counter? I could use separate per-thread counter, > incremented during up call, but I don't see much benefits form it. If > you don't want it to be system-wide accessible to not relax people too > much, I could create GEOM-specific wrapper for it. I don't really have a better option than using it. Please at least make a wrapper macro as Adrian suggested around td_no_sleeping. -- John Baldwin