Re: Threads within the kernel
site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Consider this an educational question for now. I'm considering switching things back to the way they were before, which aleviates the problem ... and thus the need for a solution, but I'm still interested in what's going on in the kernel. My observation is that there is a difference between threads associated with user processes and those "spawned" by a call to bsd_timeout(). There is this lengthy (~15 seconds) calculation that takes place in response to input from the user app. In a previous version of this program, that happened directly within the thread associated with the user process which called send() to give some input to the kernel extension. The effect was that send() blocked for those ~15 seconds but the rest of the system behaved normally. When this same calculation takes place within a thread "spawned" by bsd_timeout(), the whole system[1] seems to lock up. I can't even move the mouse. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Dec 11, 2006, at 4:32 PM, Curtis Jones wrote: Anyway ... can anyone articulate the difference? You don't really want to do this; in addition to the priority inversion that Quinn talked about, you also have to worry that the operation is not happening in the context of the process that initiated it - it's happening in the kernel context instead. This is in fact why it had the rights to effectively take over the machine in the first place. This means that if your driver does this, it's going to do the operation with root privileges (which is likely not what you want), and it's going to do it in such a way that it won't be able to directly communicate with the user process (e.g. via copyin, copyout, etc.) because it won't have a handle on the users address space map to be able to do the job. In other words, bsd_timeout() should be used to wake up user processes whose own threads happen to be blocked on a wait channel (sleep/tsleep/ msleep address), and the work should be done in the thread that woke up once there was more work to do in behalf of the process requesting that it be done. If the user process needs more threads to do its thing, it should start them itself; this also prevents the process from running away with the store accidently, since only a privileged process is permitted to try. This email sent to site_archiver@lists.apple.com
participants (1)
-
Terry Lambert