Re: GnuStep Re: X is painful
Bill Bumgarner <bbum@friday.com> writes:
> BTW: For now, I'm using the built in MIT_POSIX_THREADS. Who is =
> maintaining LinuxThreads-- it seems like a superior package and I would =
> like to move to it as soon as possible...
There are a number of issues to consider when thinking about threads
for Debian.
First of all. We probably shouldn't consider LinuxThreads and
Provenzano's pthreads (henceforth just called pthreads) mutually
exlusive. They serve different purposes. LinuxThreads provides
kernel level threads, while pthreads provides user level threads.
Sometimes one is appropriate, sometimes the other. User level threads
generally have *much* lighter weight context switches. Kernel level
threads can be scheduled by the OS, and can be run on multiple
processors.
In the long run, you'd like something like the SUN system which (I've
heard) allows both. There, you can spawn any number of kernel level
threads (each of which can run on a separate CPU), and on top of each
kernel level thread, you can run any number of user level threads.
In the short run you just want to have it so that your threaded
program won't risk segfaulting if linked against Debian libraries like
X. Right now your program will risk a crash because X has not been
compiled with the thread safe headers (AFAIK). This means that when
the X library calls something like getc (which is normally a thread
unsafe macro that was compiled into the library when X was compiled),
it may cause a race condition, die, or who knows what.
I think we'd like to have all the Debian libraries compiled in such a
way that this won't happen (as long as it doesn't impact non-threaded
programs). Unfortunately, I'm not exactly sure what's involved in
making this happen. I use pthreads here all the time, but I use pg++,
and just have to avoid things like X (unfortunately), recompile them
with pg++, or cross my fingers. I think pg++ is just a wrapper around
a call to my normal g++ that makes sure the right pthreads headers are
included in place of the normal system headers...
It would be nice if we could compile all the libraries so that they'd
work fine with either LinuxThreads or pthreads, then the choice of
which kind of threads to use could at least be made on a program by
program basis, even if we can't yet support both in the same program.
Finally, a friend of mine mentioned that there was at least one
problem that he suspected with LinuxThreads. It seems that it has to
redefine errno as a macro to get thread safe errno behavior. However
this only works if you recompile *everything* to use the macro. How
this affects things like the kernel and libc, I'm not sure.
Provenzano's threads avoid this problem by using a thread context
switch handler to make sure that a thread swaps it's own errno value
into the global variable whenever it's running. You can't do that
with LinuxThreads since it uses clone, and there's no such thing (that
I know of) as a kernel level context switch handler.
Sorry if this was too long, but I wanted to make sure that all these
issues were at least aired once.
--
Rob
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: