Date: Sun, 21 Nov 1999 00:21:53 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Julian Elischer <julian@whistle.com> Cc: freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <38378171.82BE24C3@vigrid.com> References: <Pine.BSF.4.10.9911202031230.6767-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > > On Sat, 20 Nov 1999, Daniel M. Eischen wrote: > > How about an approach similar to Solaris? Deliver the signal to either a > > special KSE/thread that acts as a proxy for the other threads? Or even > > use an activation to notify the UTS of signals. From the UTS point of > > view, notification through an activation might be simpler since we already > > have to handle them (activations). > > We need to define EXACTLY what an activation means in our context. > it's an upcall, but are all upcalls the result of a prior downcall, (or > even a downcall that 'forked a new KSE')? how does an upcall know what to > do whej it goes up? I'd say that all upcalls are _not_ necessarily the result of a prior downcall. A subprocess that is preempted should force an upcall on the next available subprocess. I assume the UTS will install a set of upcall entry points to handle async notification events. We just need to define what events are passed between the UTS and the kernel. > My suggested idea is that the UTS does a blocking syscall > that notifies the kernel that it is now capable of receiving upcalls, > and the kermnel duplicates that KSE and stack and returns on a new > KSE. The UTS knows when it returns, to immediatly allocate a new stack > and thread (probably already allocated and waiting before the downcall > actually) and switches to the new stack (or maybe the downcall was > already done on the new one in which case it restarts the old thread. In > any case the thread that did teh downcall is teh nominated handler of > async events. That's OK, but why not use a ucontext passed in with a new system call? Make the UTS supply ucontexts (made with makecontext) for event notifications also. 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?38378171.82BE24C3>