Date: Sat, 29 Sep 2001 21:44:03 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Alfred Perlstein <bright@mu.org>, Julian Elischer <julian@elischer.org>, arch@FreeBSD.ORG Subject: Re: KSE next steps... Message-ID: <Pine.SUN.3.91.1010929212212.23557A@pcnet1.pcnet.com> In-Reply-To: <3BB6106A.A44644BB@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 29 Sep 2001, Terry Lambert wrote: > Daniel Eischen wrote: > [ ... pthread_kill ... ] > > > Think of this as kill() on a process; it shouldn't be too different. > > If PCATCH is specified in the tsleep, then it is terminated immediately, > > otherwise it just remains pending until (and if) it is checked at a > > later point in time. Regardless of whether PCATCH is specified, the > > thread never returns to userland. The UTS is notified through an > > upcall in the same way that it would be if a thread blocked (but with > > a different completion status). > > You need to read the manual page for pthread_kill(3P). > > Minimally, > > #include <signal.h> > > int > pthread_kill(pthread_t thread, int sig); > > ...meaning that you can send _any_ signal, not just "SIGINT". The > delivery is to a specific thread. You misinterpret what I wrote. I just meant that abort_thread() behaves in the same way on a thread as kill() does on a process. The process leaves the kernel and returns to the installed signal handler (assuming the signal is unmasked). The same thing happens for abort_thread(), except instead of returning to a signal handler, it returns via an upcall. The mechanism for leaving the kernel need not be any different, except instead of using the signal trampoline to return, it uses an upcall. By default, a KSE enabled process will not get signals delivered in the normal way anyways. Signals will be delivered via an upcall, so you could just view abort_thread() as delivering a signal that can never be masked. > This pretty much means triggering the EINTR cancellation, but > doing the delivery in user space to a particular thread. The > cancellation aspect assumes, of course, that SA_RESTART isn't > specified (and/or siginterrupt(2) wasn't called). Right. But we're adding a flag to abort_thread() so the UTS can specify whether the thread's context should be saved as if it returned from the system call (with EINTR), or if it had not performed the syscall yet (SA_RESTART). -- Dan Eischen 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?Pine.SUN.3.91.1010929212212.23557A>