Re: Threads within the kernel
Re: Threads within the kernel
- Subject: Re: Threads within the kernel
- From: Terry Lambert <email@hidden>
- Date: Tue, 12 Dec 2006 21:44:02 -0800
On Dec 11, 2006, at 4:32 PM, Curtis Jones wrote:
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.
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.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden