Date: Mon, 7 Jul 2003 15:32:41 -0700 From: David Schultz <das@freebsd.org> To: Julian Elischer <julian@elischer.org> Cc: cvs-src@freebsd.org Subject: Re: cvs commit: src/lib/libpthread/thread thr_attr_get_np.c thr_cancel.c thr_getschedparam.c thr_join.c thr_mutex_prioceiling.c thr_sigaction.c thr_sigmask.c thr_sigpending.c thr_sigsuspend.c Message-ID: <20030707223241.GA94049@HAL9000.homeunix.com> In-Reply-To: <Pine.BSF.4.21.0307071410090.14379-100000@InterJet.elischer.org> References: <20030707082506.GA90638@HAL9000.homeunix.com> <Pine.BSF.4.21.0307071410090.14379-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 07, 2003, Julian Elischer wrote: > > That's what I was talking about. If you enter the UTS upon taking > > a page fault, you have to be sure that the page that faulted > > didn't belong to the UTS itself, or you at least have to have some > > way of breaking the loop. But since the UTS is unaware of page > > faults presently, I guess this isn't a problem yet. > > > > By definition, (i.e the definition of how upcalls are done) > a page fault in the UTS would block until the page was loaded and no > upcall would be produced.. This is because there is no registerred > 'thread' in the UTS's mailbox when the kernel is enterred, so > no upcall context can be created. (or, rather, the current context can > not be storred for later so the current KSE is not free to create a new > upcall context.) Thanks to both you and Dan, I am now un-confused. Moreover, it seems like someone (David?) fixed the sigwait() problems that have been plaguing me for a while now. KSE has really come a long way in the last few months!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030707223241.GA94049>