Date: Tue, 28 Nov 2000 18:51:59 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: FengYue <fengyue@bluerose.windmoon.nu> Cc: David Petrou <dpetrou@cs.cmu.edu>, freebsd-hackers@FreeBSD.ORG Subject: Re: thread model questions Message-ID: <20001128185159.W8051@fw.wintelcom.net> In-Reply-To: <Pine.BSF.4.21.0011281830220.58291-100000@shell.unixbox.com>; from fengyue@bluerose.windmoon.nu on Tue, Nov 28, 2000 at 06:32:15PM -0800 References: <Pine.BSF.4.21.0011281826500.58291-100000@shell.unixbox.com> <Pine.BSF.4.21.0011281830220.58291-100000@shell.unixbox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* FengYue <fengyue@bluerose.windmoon.nu> [001128 18:31] wrote: > > On Tue, 28 Nov 2000, FengYue wrote: > ->->No it wouldn't. The async nature of the call would prevent the > ->->process from blocking therefore the threads wouldn't block either > ->->blocking. > ->-> > -> > ->Sorry for being unclear. I actually meant "Would the async system calls > ->considered the case for 'preemptive at kernel level'". > > Never mind, I see what you meant:) Would you mind give me > a scenario which is considered as preemptive at kernel level for fbsd > threads? Thanks. FreeBSD 4.x: Once you're running in the kernel you are not preemptive until you explicitly yeild via tsleep or an interrupt you haven't masked via spl comes in. Even if an interrupt comes in you will only be preempted to allow that interrupt to complete, then you will resume running until you sleep. This means that if you have an expensive codepath in the kernel you can exceed your timeslice by quite a bit before letting go of the processor. In FreeBSD 5.x we hope to be mostly preemtable. -- -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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001128185159.W8051>