Date: Tue, 10 Jul 2001 00:23:40 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Julian Elischer <julian@elischer.org> Cc: Jason Evans <jasone@canonware.com>, arch@FreeBSD.ORG Subject: Re: help needed in threads.. (Signals) Message-ID: <Pine.SUN.3.91.1010709233432.1898A-100000@pcnet1.pcnet.com> In-Reply-To: <Pine.BSF.4.21.0107091220140.48707-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 9 Jul 2001, Julian Elischer wrote: > > BTW have settled on names... > ksec is gone.. please use "thread" > ksegrp and kse remain. OK, but it is confusing to refer to thread in userland and thread (context) in kernel. It's not immediately obvious which one is being referred to. > On Mon, 9 Jul 2001, Daniel Eischen wrote: > > > The UTS needs tell the kernel to interrupt a specific blocked thread. > > If the ksectx is not interruptable at its current point, then the > > kernel needs to mark it as having a signal pending on it so that the > > signal handler (or upcall) can be called when it either becomes > > interruptable or is ready to return to userland. > > In my plan, the signal will be delivered on > the next upcall (which could be immediatly) > on ANY KSE in the process. If there are no runnable KSEs > on the process, one will be made runnable to force an upcall. Yes, I think we've talked about that. I don't have any problem with it. I'm now only concerned about how to deliver the signal to the correct thread (after the original upcall). > It will be up to you to decide what to do with it. > You will have tools to help you with this, which include: > 1/ The ability to pre-empt a given thread in user mode (on another > processor obviously, as if it were on the same processor then it obviously > has already been pre-empted. Does each KSE always start (after being preempted) with an upcall? We don't want to use the Linux method of communication between threads (using signals). I just want to make sure that we have all the tools necessary to make this work. > 2/ The ability to (try) abort with a signal, any thread that is blocked in > the kernel. > 3/ The ability to make a thread yield and do an upcall > on return from a non-blocking syscall. > (these may be the same call) > > As I see it, a thread is in 4 states: > 1/ In userspace, Not running > 2/ In userspace, running > 3/ In kernel, blocked > 4/ In kernel, running (Only in SMP, on another processor) > > transitional states are not considered as they should be locked.. > #1 requires no assistance > #2,3,4 require kernel asistance to ensure that the UTS can > take control of the thread to ensure it receives the signal. > > The UTS cannot deliver the signal until the kernel tells it that the > > ksectx is either interruptable or completed. I'm not quite sure what > > happens in a normal trampoline; if a signal handler completes > > normally, does it go back to the same spot in the kernel to finish its > > work (assume SA_RESTART is set)? > > No, the syscall is restarted from the beginning I think. > I'll check. > > the whole restart thing is a can of worms > Does the posix threads spec say that syscalls should be restartable? > Maybe we can say "no, not under threads they aren't". I don't think it wise to go down this road. If at all possible, and I don't see why it would be that difficult, we should make system calls behave the same in a threaded program as they would in an unthreaded program. We already handle this in an unthreaded environment. I don't think POSIX makes an exception for this in a threaded environment; I'll check to make sure. We also don't want to have the threads library wrap these system calls to produce the correct behaviour. > > If so, I think the interrupted > > ksectx needs to be set to the current ksectx when the interruption > > occurs. The UTS has no idea whether the invoked signal handler is > > going to return normally or not. (If the signal handler longjmps out > > of the handler, you need to make sure the ksectx isn't left forever in > > the kernel.) > > I would say that the thread always returns all the way out of the > kernel, and if the library wants it to be restartable, it can do it > itself. I don't agree with this. The kernel knows whether the system call is restartable. We don't want to do this in the threads library (see above). All we basically need to do is the same thing we do in an unthreaded application, except that we do it under direction of the UTS (via a new system call). The sigacts can even be used to pull out the address of the handler since it will be unused for normal (initial) signal delivery. Here's what I'd like to see: __sys_kse_kill(int kse_id, int sig) If the kse_id (or thread id, whatever we use to identify the thread blocked in the kernel) is interruptible, the kernel makes the thread (kse context) current, copies out the trampoline code as it would in an unthreaded environment (ignoring sigstack and using the threads user stack), and returns to the installed signal handler. If the kse_id (thread) is not interruptible, it marks the signal as pending (only on that thread) and returns an appropriate error to denote that the thread is busy and will be interrupted as soon as possible. -- 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.1010709233432.1898A-100000>