Date: Mon, 9 Jul 2001 19:41:09 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Daniel Eischen <eischen@vigrid.com> Cc: Jason Evans <jasone@canonware.com>, arch@FreeBSD.ORG Subject: Re: help needed in threads.. (Signals) Message-ID: <Pine.BSF.4.21.0107091220140.48707-100000@InterJet.elischer.org> In-Reply-To: <Pine.SUN.3.91.1010709084741.15060B-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
BTW have settled on names... ksec is gone.. please use "thread" ksegrp and kse remain. proc ksegrp kse thread After I started looking at what I was going to need to do it became obvious that the term "thread" was going to make the most sense here. (it has a 1:1 correspondence with user level threads too) 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. 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. 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". > 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. Basically the syscall returns and is 'yield()ed as normal, and then an upcall occurs with notification about the signal. > > > I guess I should ignore all signals when in KSE mode and just pass them up > > as an upcall. > > (The kernel interface and the user interface need not be the same). > > > > This indicates that a signal pre-empts whatever is running to do an upcall > > rather than > > waiting until i gets a chance that may never happen. > > (hmmmmm I need to think about this more... off to bed..) > > On a related note, the UTS needs another system call to send a > message from one KSE to another (possibly set of) KSEs. The > UTS does direct handoff of mutexes, condition variables, and > other things. If the handoff is to a thread running (now > waiting) on another KSE or KSEG, then the we need to be able > to "signal" it that that thread should now be runnable. > A similar thing for signals. If the thread that needs the > signal dispatched is scheduled on another KSE, then we > need to send that KSE a message to inform it of that. I > say "possibly set of" KSEs because of pthread_cond_broadcast(). The waiting thread is not going to be in kernel space.. It will be waiting in userspace. All that will be needed is a call to bring back to life any previously surplus KSEs. I'm not sure how the kernel gets involved here.. > > -- > 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.BSF.4.21.0107091220140.48707-100000>