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>