Date: Fri, 24 Nov 2000 02:08:40 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: eischen@vigrid.com (Daniel Eischen) Cc: tlambert@primenet.com (Terry Lambert), bright@wintelcom.net (Alfred Perlstein), jhb@FreeBSD.ORG (John Baldwin), jlemon@flugsvamp.com (Jonathan Lemon), arch@FreeBSD.ORG Subject: Re: Thread-specific data and KSEs Message-ID: <200011240208.TAA06691@usr06.primenet.com> In-Reply-To: <Pine.SUN.3.91.1001122180746.7920B-100000@pcnet1.pcnet.com> from "Daniel Eischen" at Nov 22, 2000 06:17:30 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > The %gs register already has to be saved for WINE processes, > > so it's taken (at least when USER_LDT is defined). So there > > would not be an additional context switch for it. > > Are WINE processes threaded? Do we really care? You probably don't care, but in Windows programs, the code is the same for all event sinks, and it's the %gs register which is used to get the data segment context. In WIN32, this is basically a "thread ID". In Windows with multiple instances of the same program, the data segment is the "program ID", and it's how programs differentiate from each other when sending events, etc., and how the OS does the same. You probably don't care because it only means that the register is saved and restored on a per process basis already, and can't really be used with an indirect, due to the assumptions of WINE. You could implement a double indirect going to user space, but you would need to store a copy of the table pointer in the proc struct, and then dereference whatever element was the "WINE %gs" element for WINE processes going back to user space. As a general mechanism, you could dereference the thread element going back to a threaded program in user space; this is somewhat gross, in that it means that you would only get one element per applcpiation domain, instead of as many as you wanted, and you would have to recognize the application domain from kernel space (but you would have to do this anyway, for WINE programs). This kind of hints at either a general mechanism, or a different register and a general mechanism, to avoid conflict with WINE. In the second case, you could leave the table reference intact going to user space, and it would make the interface reflexive, and not limit you to one element (or put another way, your application could be in more than one application domain at the same time, using this approach). > If you have an API in mind, send it to me. "current thread" is > used an awful lot in the threads library and I'd like to avoid > any uncessary levels of indirection, which is one reason I'd > like to do it the way jhb suggested. I think you should do the extra indirect, because you can't tell what the future will bring in terms of people needing to communicate per scheduling entity information around. I would go so far as to suggest that the per CPU stuff should probably be similarly abstracted, to allow for future uses which we haven't considered yet there, either. Worst case, the architecture specific data could be seperated. I suspect that someone, somewhere, is working on an OS like the one at the University of Utah, using source code to migrate processes between dissimilar architectures (as one over-the-top example). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?200011240208.TAA06691>