Date: Tue, 15 Oct 2013 15:24:00 -0400 From: John Baldwin <jhb@freebsd.org> To: Alexander Motin <mav@freebsd.org> Cc: svn-src-projects@freebsd.org, Adrian Chadd <adrian@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org> Subject: Re: svn commit: r254846 - projects/camlock/sys/cddl/contrib/opensolaris/uts/common/fs/zfs Message-ID: <201310151524.00731.jhb@freebsd.org> In-Reply-To: <525CF9FC.2000109@FreeBSD.org> References: <201308251121.r7PBLA3v033536@svn.freebsd.org> <201308261425.34743.jhb@freebsd.org> <525CF9FC.2000109@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201310151524.00731.jhb>