From owner-freebsd-arch@FreeBSD.ORG Thu Nov 20 00:04:48 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8190F106564A for ; Thu, 20 Nov 2008 00:04:48 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from outbound.icp-qv1-irony-out4.iinet.net.au (outbound.icp-qv1-irony-out4.iinet.net.au [203.59.1.150]) by mx1.freebsd.org (Postfix) with ESMTP id EC5B18FC12 for ; Thu, 20 Nov 2008 00:04:47 +0000 (UTC) (envelope-from lstewart@freebsd.org) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACM2JEl8qEpL/2dsb2JhbADTLYJ5 X-IronPort-AV: E=Sophos;i="4.33,635,1220198400"; d="scan'208";a="278606325" Received: from unknown (HELO lawrence1.loshell.room52.net) ([124.168.74.75]) by outbound.icp-qv1-irony-out4.iinet.net.au with ESMTP; 20 Nov 2008 08:52:31 +0900 Message-ID: <4924A6BE.8080308@freebsd.org> Date: Thu, 20 Nov 2008 10:52:30 +1100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.17 (X11/20081109) MIME-Version: 1.0 To: Julian Elischer References: <492412E8.3060700@freebsd.org> <49245D3B.8050607@elischer.org> <49248958.9060308@freebsd.org> <49249624.7020108@elischer.org> In-Reply-To: <49249624.7020108@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: kthread_exit(9) unexpectedness X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2008 00:04:48 -0000 Julian Elischer wrote: > Lawrence Stewart wrote: > >> I'm not sure I'm clear on why the wakeup behaviour is part of the KPI >> though. The documented behaviour in the 7.x kthread(9) man page is >> that it calls wakeup() on the "thread handle". So the documented >> behaviour is the intuitively correct one. The actual behaviour is >> "wrong", although historically consistent. > AH > > I thought you said the documentation for kthread didn't mention teh > wakeup.. > so, we should probably MFC the fix > I said the 7.x kthread(9) man page mentioned the wakeup(), the 8.x kthread(9) man page does not. This definitely needs to be corrected. > > [...] > >>> >>> which one would you change? >> >> heh, good question. >> >> On the one hand we have the intuitively correct behaviour in 8.x, >> although the 8.x kthread_exit() behaviour with respect to wakeup() is >> not documented at all in the kthread(9) man page. > > patch suggested :-) Can do. > >> >> On the other, we have the 7.x documented behaviour which is correct, >> but the actual behaviour of the code (which is historically >> consistent) is incorrect and at odds with the 8.x behaviour. > > in 7.x nearly everything uses kproc... so we could probably safely > change it now. We could definitely change it for all in tree cases easily enough. My concern is out of tree code. This change would make any out of tree code that relies on the actually implemented wakeup() mechanism potentially deadlock, which is not nice. We could argue that the documented behaviour is correct and that we're correcting a bug with the fix... still, tis cold comfort for anyone who's working code now deadlocks. I do like the maintenance simplicity the change would bring moving forward. I'm still not sure the code change is the best idea. Does anyone else have thoughts on the matter? > >> >> I'm playing devil's advocate here as now I'm curious whether this >> issue is really considered part of the KPI or not. If the actual >> behaviour is what's important, then we obviously can't make the change >> in 7.x. If the documented behaviour is what we are supposed to be >> honoring, then technically the change could be made, no? >> >> Devil's advocate musings aside, my personal feelings are that we >> should be aiming for intuitive correctness in the KPI i.e. leaving the >> 8.x code as it is makes sense. Even though I feel the wakeup() >> behaviour is not technically part of the KPI in 7.x, I don't think we >> should change the code. >> >> Therefore I would propose some improvements to both the 7.x and 8.x >> kthread(9) man pages which clearly document the actual behaviour and >> subtle differences between 7.x and 8.x. >> >> I also suspect an entry in UPDATING should be added close to the >> existing 20071020 entry that retrospectively discusses the switch and >> the subtle difference in kthread_exit() behaviour. >> >> Finally, mentioning that the value of __FreeBSD_version can be checked >> against 800002 using an #ifdef test to conditionally detect which >> behaviour should be used would also be a good idea. >> >> The above changes should equip developers with all the info needed to >> maintain code that crosses the 7.x/8.x gap with minimal loss in hair. > > from MEMORY the wakeup and sleep are both done inside our own > functions and the user is not expected to do them himself. > so as long as we fix it on both sides.... > (I may be wrong on that, I haven't looked at the code but just memories..) Not sure what sleep you're referring to, but yes we say we don't require the user to do their own wakeup() as their thread dies. Though consumers of the API in 7.x and 8.x might have worked around the difference in behaviour by adding their own wakeup() (it's how I did it initially before digging a bit deeper). Cheers, Lawrence