Date: Sat, 24 May 2003 02:54:17 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: Julian Elischer <julian@elischer.org> Subject: Re: libkse and SMP (was Re: USB bulk read & pthreads) Message-ID: <3ECF4149.EDCDD1B6@mindspring.com> References: <Pine.GSO.4.10.10305240234060.15741-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: > On Fri, 23 May 2003, Terry Lambert wrote: > > I'm rereading it, but I don't see that interpretation. > > > > I guess if both you and Julian both called me on it, I must > > have misexpressed myself, but I currently don't understand > > how. 8-|. > > I think it was the part about "a single CPU system with > PTHREAD_SCOPE_PROCESS (the default) can still get itself > blocked in the kernel by a single blocking call" without > mentioning that it won't block other scope process > threads from being run. OK... this I don't get. If the scope is process, and you are implementing M:N, and N == 1, my understanding of the code is that it will block exactly the same as libc_r. If it won't (and I'm prepared to believe this), then I'd like to know "why not?"; it should be that there is a single scheduling object, no? Reading the code, I don't get that there will be the ability to do multiple returns. Is it that a KSEG is intended to represent a quantum? If so, I've just had an epiphany as to why you would want KSEG's at all in the first place (I've never agreed with Julian on KSEG's, since the earliest days, and I've only reluctantly accepted their necessity as an artifact of scheduling priority differences for a strictest compliance with POSIX mandated semantics -- hence my defense of them to Jeff when he wanted to change the kernel code to make them semi-impossible). -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ECF4149.EDCDD1B6>