Re: Query regarding newlib and glibc

[Jeff Johnston <jjohnstn at redhat dot com>]

Vitus Jensen wrote:
> Jeff Johnston wrote:
>
> ...
>
> > It has been suggested that the libpth library might be integrated into 
> > newlib for the non-linux situation.  I had prototyped such a solution 
> > and abandoned it because it could not fulfill the needs of the EL/IX 
> > standard due to the fact that the threading model is non-preemptive.  
> > With all the recent requests for threading, I need to dig this code 
> > out, provided it still exists.  A number of changes were required, but 
> > I can't think of them off-hand; it was a while ago.
>
>
> Hi Jeff,
>
> I'm very much interested in newlib and threads as our OS supports 
> preemptive multithreading.  So far we have only created single threaded 
> applications using my newlib port, but there are strong requirements for 
> threads.  We can do threads using our old RTL but newlib is so much more 
> complete that newlib + threads is very much preferred.
> Do I have to understand your message so that what you have in mind 
> wouldn't help us as our OS isn't unix-like and your changes wouldn't 
> support preemption?  :-(
> BTW: it's m68k code.

Unfortunately, the libpth solution is non-preemptive.  It also requires some 
Unix functionality not present in vanilla newlibs, however, one could argue that 
any embedded platform looking to support POSIX-like threading isn't a vanilla 
platform to begin with.

Perhaps you could look at seperating out and modifying the threading code of 
your old RTL to cooperate with newlib.  Essentially, you just need to switch the 
reentrant structure for newlib via __getreent.  This is one of the changes I 
made to support linuxthreads.  I dynamically allocated and initialized a new 
reentrant struct per thread and kept that info around in the thread-specific 
data.  Thus, my __getreent() function became quite simple.

-- Jeff J.