Date: Mon, 27 Aug 2001 08:02:22 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Julian Elischer <julian@elischer.org> Cc: tlambert2@mindspring.com, Archie Cobbs <archie@dellroad.org>, arch@FreeBSD.ORG Subject: Re: changes to BSD APIs for THREADS support Message-ID: <Pine.SUN.3.91.1010827075542.3232A-100000@pcnet1.pcnet.com> In-Reply-To: <3B89D7F1.74D834C9@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1010827075542.3232A-100000>