From owner-freebsd-arch Sat Sep 29 18:45: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id ED18637B408 for ; Sat, 29 Sep 2001 18:45:02 -0700 (PDT) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id VAA26144; Sat, 29 Sep 2001 21:44:03 -0400 (EDT) Date: Sat, 29 Sep 2001 21:44:03 -0400 (EDT) From: Daniel Eischen To: Terry Lambert Cc: Alfred Perlstein , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE next steps... In-Reply-To: <3BB6106A.A44644BB@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 > > 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