Messages in this thread | | | From | "Khimenko Victor" <> | Date | Wed, 28 Jul 1999 00:24:23 +0400 (MSD) | Subject | Re: Q: Thread local storage, thread IDs |
| |
In <379DEFFC.5208531A@trantor.de> J÷rg Pleumann (joerg.pleumann@trantor.de) wrote: > Hello Chris,
> cd_smith@ou.edu wrote:
>> > (2) 1-based IDs for the threads belonging to a process (in addition to >> > the system-wide unique process IDs). >> >> What do you mean by 1-based? Do you mean that you want to require that >> the first thread in a process always has TID 1? That's pretty kuldgy, and >> very non-portable if you actually use it. If you need 1-based ID's, use >> TLS and a mutex-protected global variable and have threads allocate their >> process-local ID at startup and then increment the counter.
> I need 1-based thread IDs because the thread local storage mechanism > implemented in the Pascal compiler run-time library expects 1-based IDs > for a simple lookup of a thread variable's value in a table. Kind of
> address(variable) + (tid - 1) * total_tls_size.
> It all works only for global variables, so total_tls_size is a fixed > value for the program. I guess it's exactly what Delphi does. I could > change this, of course, but I don't want to make more changes to the > original RTL than absolutely necessary.
Adding such stuff to kernel looks MUCH worse to me then fixing RTL. I hope you'll be unable to pass it over Linus anyway :-)
>> I doubt that the kernel really does any screwing around with the values of >> registers for the context. If so, I've lost a lot of what respect I >> previously had for any of these operating systems. More likely, the use >> of FS for that purpose is a convention used by the program, and the kernel >> properly context switches, without caring what you're using your registers >> for.
> In OS/2 and Windows, the FS selector *initially* points to a thread > information block for the current thread. Of course you can change the > value of FS, and this value will still be valid after a context switch. > So the use of FS the way I described it is really a convention used by > the program (and recommended by the OS). But I don't see how I can > implement this convention in my program if the Linux kernel forces me to > use
> ds=es=fs=gs
> and doesn't allow me to create a new selector/offset pair for a given > address. On the other hand I'm not such an i386 protected mode assembler > geek, so it is possible that I've missed some command while browsing > through my assembler books.
Linux uses FLAT address space. And FLAT means exactly this: flat. No selectors. In userspace that is. No way to create new selector and no need to change [csdefg]s at all. You'll need really, really, REALLY strong argument to change this. And even then such patch will be rejected :-)) No way, sorry. Linux 2.2 uses 1 selector per process (for TSS) and 2.3 does not use even one selector per process and it's worth it.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |