Date: Tue, 13 May 2003 13:05:17 +0800 From: "David Xu" <davidxu@freebsd.org> To: "Julian Elischer" <julian@elischer.org>, "Peter Wemm" <peter@wemm.org>, "John Baldwin" <jhb@freebsd.org>, <threads@freebsd.org> Subject: Re: Multiplexed threads signals. Message-ID: <00c001c3190d$412d8f80$f001a8c0@davidw2k> References: <Pine.BSF.4.21.0305121711350.94099-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I think we should implement single and not upcall enabled thread group now(system scope thread), because this kind of thread can=20 always be identified by kernel, so unlike multiplexed group, we can always redirect signal to that thread in kernel. in libpthread, creating one or more dedicated signal thread to receive async signals, these threads can use sigwaitinfo syscall to retrieve any async signals, these threads also redirect signals to threads in userland which are multiplexed, or, if posssible, these threads can also handle signals in userland directly without need to redirect signals to other threads.=20 whenever other processes or current process want to deliver async signals to the KSE process, one of those system scope threads is selected to delivering signal, td_sigmask can be used if a system scope thread does want to receive a signal at that time, if none of such system scope threads wants to receive signals, queue signal in process siglist, until some of them want to receive signal again. sync-signals are delivered as normal thread/process. I think most code are already in kernel. David Xu ----- Original Message -----=20 From: "Julian Elischer" <julian@elischer.org> To: "Peter Wemm" <peter@wemm.org>; "John Baldwin" <jhb@freebsd.org>; = <threads@freebsd.org> Sent: Tuesday, May 13, 2003 9:11 AM Subject: Multiplexed threads signals. >=20 > I'm looking at trying to work out who is to deliver a signal in an M:N > process. We never answered some of these questions.. Altering ht ecode = I > find that I need to answer them now.. >=20 >=20 > This started off as a comment in the code but it kept growing... >=20 > better to discuss it... >=20 > /* Here we need to decide our policy > * with respect to waking up threads for async signal > * delivery. Generally in this library, async signals are not > * actually delivered to teh process, but rather a notification is = > * delivered during an upcall with a mask similar to that=20 > * used in the sigpending() call, and the library 'fetches'=20 > * the waiting signal using sigwait(); >=20 > (0) - threads in sigwait for the signal get first crack. >=20 > (1) * Firstly, if we interrupted a thread in userland, > * don't wake up ANY kernel threads, When we finish=20 > * it's going back. It can take the signal with it.. > * SYNC signals take this path, but do not create upcalls. > * Async signals only do this if there is an upcall possible. >=20 > I think that is probably ok.. > Only async calls proceed beyond here. >=20 > (2) * Secondly we will look for an idle upcall > * and make it do an upcall. Better to bring up > * another upcall than to interrupt a thread that > * may not deserve being interrupted. >=20 > Not really a problem. > =20 > (3) * If there is a thread runnable that is going > * to return to userland upon resumption > * (i.e. been pre-empted). Set its bit and > * let it handle it. Maybe give it a boost > * if its low priority. If several, choose > * highest priority. Don't do this if an upcall > * is not possible, for that thread. > * An actual upcall thread takes priority. >=20 > Existing code will force this to convert to an upcall > on transition to userland. >=20 > (4) * If there is a thread actually running NOW > * on another CPU and in userland, whack it > * with an IPI and leave the rest to it. > * We can not tell if it will create an upcall > * on getting whacked since we can't look at it's > * upcall mailbox. >=20 > This results in option (1) for the other thread. > But if it's in the UTS, no upcall will result. > If this happens we are left with an un-notified signal, but > at least we know that there will be at least one thread coming down > eventually. if a process decides to run in purely non-upcall mode, > then we can not deliver any async signals to it.. This could be a > problem. This suggests that we need a way to deliver signals without > the complicity of the UTS. Maybe if the next upgoing thread > is not capable of doing an upcall, we just deliver on the stack as per > normal. >=20 > * To some extent > * this suggests that we look for pending signals > * when ENTERING the kernel for a syscall. One could > * make the point that it MIGHT have received a clock > * interrupt 1 instraction before enterring the syscall, > * and then continued on to do the syscall. > * This would be akin to returning an ERESTART > * but before actually doing the meat of the syscall. >=20 > Peter suggested that we keep a per-KSEGRP mask > (lazily set) and that if we encounter a ksegrp with a signal > unmasked and registered as not multiplexing, we just deliver up to it = as > on its stack.. (i.e. system scop threads just get signals as per = normal) > this coincides with what libthr does in the degenerate case. >=20 > Julian >=20 >=20 >=20 >=20 > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to = "freebsd-threads-unsubscribe@freebsd.org" >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00c001c3190d$412d8f80$f001a8c0>