Date: Tue, 10 Jul 2001 08:23:33 -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.1010710080954.5316A@pcnet1.pcnet.com> In-Reply-To: <3B4A9AC1.BE93ECCF@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 9 Jul 2001, Julian Elischer wrote: > Daniel Eischen wrote: > > > > Does each KSE always start (after being preempted) with an upcall? > > This is up for discussion but generally: > yes OK, good. This allows the upcall to look for any pending messages (from other KSEs) before it resumes/starts a thread. > > 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.. Right, it just makes it harder because you may have to use locks to protect this 'shared memory', and you'll be doing this from the UTS (upcall). If there was a general way to send messages between KSEs, I think it would be a lot cleaner. But if each each KSE is always started with an upcall, then that gives it a chance to look for any pending messages. -- 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.1010710080954.5316A>