Date: Fri, 26 Nov 1999 19:16:36 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Julian Elischer <julian@whistle.com> Cc: arch@freebsd.org Subject: Re: Threads stuff Message-ID: <383F22E4.31155FC7@vigrid.com> References: <Pine.BSF.4.10.9911261503050.544-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > > > Why does the UTS need any of this, though? It just needs notification > > that the thread blocked and some "thingy" that can be used to resume > > or cancel it? > > When the syscall blocks, the saved information above is to be turned into > a full frame. The PC (eip) is added (pointing to where we want it to > resume when the IO completes) and the thread is set up looking as though > it's waiting on it's IO completion block. The UTS gets (actualy should > already know) the KSE-ID. > > On completion of the IO, the io completion block is updated > just as it would have been had the syscall not blocked, and > the KSE is hung off the subprocess. When the subprocess is next run, > an upcall is made to the UTS, with some ID to let it know which > completion block to look at. This is simply the same as is some > other thread had released a mutex. The whole KSE in fact need not be hung > off the subproc because all that is needed is the single mutex address > to report. So when the IO completion block is updated, how exactly is the the thread continued? It _has_ to go back into the kernel in order to resume. I don't see the similarity between threads blocked in userland (on a mutex) and threads blocked in the kernel. > > How do you resume the thread? Longjmp'ing to the blocked system call > > won't work because the kernel doesn't know if it's a new system call > > or one that is being resumed. > > If the userland context of the thread looks just like the context of > any other thread, then you just run it. > When the thread is reported as blocked, you fiddle the context it left > behind to make it look like it's blocked on a mutex on the io completion > block. when the syscall completes, the result is the equivalent of > releasing that mutex. i.e. the thread continues. What I don't quite see yet is how you resume a thread at the kernel level. You can't just "run the thread" after the IO control block was updated indicating that the thread unblocked. You need to resume the thread within the kernel. As long as you need a kernel call to resume/cancel a blocked thread, why try to hide it behind smoke and mirrors ;-) Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?383F22E4.31155FC7>