Have you looked at more recent sources? For example, there is now a
__DYNAMIC_REENT__ flag which tells newlib you will be providing a
routine __getreent() to select the current thread's reentrancy structure.
OK. It seems like this macro is defined in config.h if the __linux__ define
is active. I suppose I can change here to make it active for __RDOS__
as well.
Besides, I remember why I had to patch for this in 1.10. Without a
function call to get the current thread's reent structure, you must
modify the pointer with every thread-switch. This was pretty much
out of the question since RDOS have kernel threads.
This removes the need of the user-code to call _r routines with a
specific reentrant structure (the _REENT macro is redefined to call
__getreent()).
Yes, is this a major improvement.
In the internal code, for example, you just include errno.h and set
errno directly. The macros take care of everything so that the
__getreent() function gets called under the covers and the errno value
is placed in the correct thread context. In your situation, you could
write a __getreent() routine that referred to a special pointer in TLS
that is initialized at thread creation.
Yes, this is how I patched 1.10 too. I let the thread-creation code
allocate a FS selector unique to each thread. Since a thread-switch
saves all registers, this works as it should.
Also note there is a implementation of linuxthreads in the
libc/sys/linux /linuxthreads directory that builds for i386. Newlib
altered the linuxthreads code to add the initialization of the
reentrant structure for new threads and placing the pointer in a
control structure to be accessed at any time. If you supply most or
all of the syscalls that Linux does, you probably can use a great deal
of the thread code.
Isn't linuxthreads an application implementation of threads rather than
a kernel implementation?