Date: Thu, 5 Oct 2000 15:15:04 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Terry Lambert <tlambert@primenet.com> Cc: Mark Murray <mark@grondar.za>, Jake Burkholder <jburkhol@home.com>, Boris Popov <bp@butya.kz>, freebsd-smp@FreeBSD.ORG Subject: Re: Problems with kthread_exit() and SMPng Message-ID: <20001005151504.K27736@fw.wintelcom.net> In-Reply-To: <200010052142.OAA15421@usr05.primenet.com>; from tlambert@primenet.com on Thu, Oct 05, 2000 at 09:42:28PM %2B0000 References: <20001005113139.C27736@fw.wintelcom.net> <200010052142.OAA15421@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Terry Lambert <tlambert@primenet.com> [001005 14:42] wrote: > > > There is another problem; printf's inside a kthread corrupt like > > > crazy. They look very unthreadsafe. > > > > do NOT use printf without Giant. > > This strikes me as being rather inane. > > If printf won't work without holging the lock, then it damn well > should acquire the lock if it isn't already held, and release it > if it acquired it, before returning. > > This is not something that a programmer should have to worry > about when they use a service; unless you are doing threads > IPC, perhaps in some vainglorious attempt to make SMP systems > stall their little butts off with interprocessor synchrnization, > this should never be an issue. > > In other words, I don't give a damn, as a programmer, whether > a service is reentrant or not, so long as it works when I call > it. Having the lock fairy sprinkle lock primitives before and > after every service call is not my idea of a Good Thing. > > > This appears to be a very good point to note that having an > owner or recursing on this lock would both end up being Very > Bad Things, since it would make the obvious and intuitive > (and therefore least astonishing) behaviour impossible. One of the options for fixing kernel logging under SMP was to have a very simple queing mechanism to send the messages to a kernel thread that would be repsoncible for the output. You see, the problem with logging is that the logging calls are in a lot of weird places, nevermind critical ones like panic, there needs to be a special relationship between the logging kthread and the system which may be difficult to set up. You also have to take into account that the output method of the driver might block therefore we need to hand off the blocking to someone else. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001005151504.K27736>