The thread model in newlib

[Leif Ekblad]

> 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?
 
> Regarding your request to not supply _r routines:  the Linux port 
> specifies -DMISSING_SYSCALL_NAMES in configure.host as it directly 
> supplies reentrant syscalls (i.e. no _r syscalls are required).  You 
> would want to do this as well.

OK, I can see how this works. 

I see that the Linux implementation has lots of code in newlib. Is this
the preferred way to support a new OS? I also see that some systems
use newlib/libc/sys while some others use libgloss/sys. What is the
difference and what exactly is libgloss?

Regards,
Leif Ekblad