Date: Tue, 23 Nov 1999 23:47:18 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: "Daniel M. Eischen" <eischen@vigrid.com> Cc: Nate Williams <nate@mt.sri.com>, freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <Pine.BSF.4.10.9911232334320.11412-100000@current1.whistle.com> In-Reply-To: <383785E5.C9193B77@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 21 Nov 1999, Daniel M. Eischen wrote: > > Now I think I understand what Julian is talking about. Suppose a read(2) > blocks in an MT application. Julian is thinking that read(2) returns > with -1 and errno set to EMTBLOCKED or something like that? Not exactly.. I think that by stack magic what actually returns is a differnt KSE and it 'returns' (so to speak) to the UTS The way that the UTS tells the kernel how these returns are made is that one time for each subproc it calls a new syscall with information as to how to get to the UTS. Basically this is a set of context that the future upcalling KSEs will use. Basically a stack is set up and the KSE "returns". In some way you can think of it as being one call returning many times. The state saved from that one downcall becomes a prototype upcall. Each subproc has to do this once, as each should have a different return context for it's upcalls. If you haven;t done this you can't get upcalls so you are effectively non multithreaded. > > I don't think a blocking system call should return at all. > Control should be returned to the UTS at another entry point > and on another stack. Certainly, OR another possibility is that ALL syscalls return to the same place? > > Dan Eischen > eischen@vigrid.com > 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.10.9911232334320.11412-100000>