Date: Sun, 26 Aug 2001 23:00:58 -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.1010826224344.27633A-100000@pcnet1.pcnet.com> In-Reply-To: <3B897729.FF577A21@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 26 Aug 2001, Julian Elischer wrote: > Terry Lambert wrote: > > > > Julian Elischer wrote: > > > Archie Cobbs wrote: > > > > Julian Elischer writes: > > > > > 5/ It is possible that we may need a call by which the user thread > > > > > scheduler can 'cancel' the syscall that a particular kernel thread > > > > > is currently operating on. (particularly if it is waiting). > > > > > > > > I think this is going to be required. The UTS needs to have the > > > > ability to cancel a thread at any time. If the thread is in userland > > > > then it can just do it; otherwise it needs a way to wake up the > > > > thread in the kernel. The thread's syscall should then return > > > > immediately with EINTR or somesuch; alternately, the thread can > > > > just never return. Mabye both options would be good to have. > > > > > > the mechanics are the same as for the current code that aborts a > > > syscall when a signal is sent to the process, except that the > > > method of finding the sleeping party to unblock is slightly different. > > > > > > The syscall returns just like the current one would until it > > > reaches the kernel boundary. (it needs to unlock and free anything > > > it may have locked or allocated on the way in). At the boundary > > > we can just let it report a failure. The UTS can then cancel it. > > > > Julian, are you talking about EINTR handling (Archie's last > > sentence), or are you talking about his whole statement? > > > > If you are talking about his whole statement, I have to side > > with Archie: a blocking O_EXCL open on something like a modem > > would never be interruptable, without the ability to explicitly > > abort the system call as part of aborting/EINTR'ing the thread > > currently blocked on the call's completion. > > I think you are getting a little carried away here.. > Basically any sleeping kernel thread must be cancelable. > When it is cancelled it must free any resources it has. > To do this it needs to rewind through it's stack to the user boundary. > When it reaches there, we can do what ever we want with it.. > My suggestion is that we report a 'cancelled' state back to the UTS, > and let it decide what to do (restart it, > erase the whole userland thread, whatever). This is the same > mechanism as used by the current code to abort a syscall when a > signal is caught (kill -9 should abort most syscalls). > the actual code returned is probably neither EINTR or ERESTART > or anything, but probably a code specific to the KSE environment. 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)? 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? -- 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.1010826224344.27633A-100000>