This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
Re: Query regarding newlib and glibc
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.