Date: Mon, 09 Jul 2001 23:03:45 -0700 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: <3B4A9AC1.BE93ECCF@elischer.org> References: <Pine.SUN.3.91.1010709233432.1898A-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: > > 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. They bare the same relationship to each other as a proc in user mode and a proc in the kernel.. i.e they are the same thing.. When a user thread crosses into the kernel, it is represented by the kernel 'thread' structure. > > > 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? This is up for discussion but generally: yes > > 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. > how threads communicate with each other when they are on different processors is tricky.. what is wrong with 'shared memory'? All that a signal can do is leave a flag for the mainline to find which is effectively shared memory anyhow.. > 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. I'm still trying to work out how exactly restartable syscalls are achieved. > > We also don't want to have the threads library wrap these system > calls to produce the correct behaviour. that's a good point. > > > > 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. my head hurts trying to figure out how to do that but I'll work on it.. > > -- > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B4A9AC1.BE93ECCF>