From owner-freebsd-arch Sun Aug 26 22:19:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id A22AA37B40C for ; Sun, 26 Aug 2001 22:19:09 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA71531; Sun, 26 Aug 2001 22:38:54 -0700 (PDT) Message-ID: <3B89D7F1.74D834C9@elischer.org> Date: Sun, 26 Aug 2001 22:17:37 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Daniel Eischen Cc: tlambert2@mindspring.com, Archie Cobbs , arch@FreeBSD.ORG Subject: Re: changes to BSD APIs for THREADS support References: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit 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 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.. > > -- > Dan Eischen -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message