threads - current_thread()

[Alex M. <kil...@ne...>]

Hello, All!

as i understand, current approach to implement current_thread() to give
pointer to per-thread variables is to derrive it from stack pointer.
certainly, that's very fast, but i don't get why should it work stably. why
that specific address should be available to mmap, and what will happen, if
it's not in some situation, system will report that there will be no more
threads?
as far as i know, SP in new thread can be at any address, if it's not
adjusted, there can be a situation when thread_t structure lies just near
the beginning of the stack. so to guarantee some stack space, twice more
should be requested, that's definitely waste of memory..

i think there could be other approaches, that are not much slower, but more
stable/portable.
for example, high bits of SP could be used as index in some table (like
allthreads[]), where pointer to thread_t is keeped (or it can be thread_t
threadtable[MAXTHREADS];). although there might be some tricks there, it
looks much more nice, as for me.. i've checked how slower it is -- with some
code, compiled with Microsoft C++ .NET 7.1 compiler there's no difference
from approach with mmap (but maybe code is just too simple, or it's pentium4
architecture, for which it sometimes doesn't matter what to execute..).

i also OS's method to get thread-local-storage (Tls* on Win32), and it
appeared twice slower than methods above.

by the way, i found that code in zthread.d doesn't call create_thread, that
actually mmap bytes under current_thread(), but it actively copies bytes
there.. unless i'm missing something, this could be a reason for SEGFAULTs
:)

With best regards, Alex Mizrahi.