From owner-freebsd-arch Mon Aug 27 5: 3:18 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 DD01837B403 for ; Mon, 27 Aug 2001 05:03:12 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id IAA04895; Mon, 27 Aug 2001 08:02:22 -0400 (EDT) Date: Mon, 27 Aug 2001 08:02:22 -0400 (EDT) From: Daniel Eischen To: Julian Elischer Cc: tlambert2@mindspring.com, Archie Cobbs , arch@FreeBSD.ORG Subject: Re: changes to BSD APIs for THREADS support In-Reply-To: <3B89D7F1.74D834C9@elischer.org> 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 Sun, 26 Aug 2001, Julian Elischer wrote: > Daniel Eischen wrote: > > > If the signal handler is installed with SA_RESTART, how does the > > UTS restart the thread after normal return of the signal handler > > (as opposed to when the thread longjmps out of the signal handler > > in which case the system call will never be restarted)? > > well the signal will be delivered to the UTS as a pure notification. > The UTS decides that it should be deliverd to thread (X). > The UTS discoveres that thread (X) is suspended in the kernel. > It sends a "cancel syscall" bomb to thread (X). > Thread (X) returns to the user boundary. > Here, we have two possibilities > (A) the kernel stores the state of the thread as if it had finished the > syscall. > -or- > (B) the kernel stores the state of the thread as if it was about to do > the syscall. > In either case, the UTS can compensate. to get the other case. > The signal trampoline code is placed on the stack of the thread. > The saved context is placed correctly in the trampoline code (as now). > The signal is processed. > The system call is either reported as failed, or re-done. (depending > on what we chose to do) > > > > > Does it save the context from just after being canceled in > > the kernel, and then munge it a bit to restart the system call > > again? Or is the context already restartable and it needs to > > be munged to bypass the system call (returning EINTR)? Can > > we tell the kernel what type of context to pass back based > > on whether SA_RESTART is set or not? > > we could do it either way.. we could even make it an argument to > the "cancel_syscall(thread, how)" syscall. > > Which ever you'd prefer.. I like the latter. Having the UTS tell the kernel how to cancel the thread with an option to cancel_syscall like you show above. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message