Query regarding newlib and glibc
Thu Oct 21 19:02:00 GMT 2004
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.
More information about the Newlib