Gavriel State wrote:
>
> Josh DuBois wrote:
> >
>
> Is there really any reason not to just use pthread directly? We're
> not constrained by binary compatability issues on LinuxPPC (or MacOS X),
> so there's no need to preserve any special registers.
>
<newbie>
Well, really I don't know. In a way I hope not;), 'cause I've been
assuming pthreads is no good, but I could be wrong.
In a discussion about threading in November (I pasted in part of an
interesting post down below) on this list someone gave a brief
explanation of why pthreads aren't used. From things like that that
I've found on the archive I assumed pthreads wasn't feasible. It seems
that if pthreads won't allow variable-sized stacks that'd be a
showstopper if Windows requires them, whether we were in binary
emulation mode or not. But I don't at all pretend to understand all the
possible related issues. I do notice that pthreads don't seem to be
used on non-intel solaris.
Can pthreads in fact be used on linuxppc?
</newbie>
> Also, if you're interested I can send you my original WINE PPC port, circa
> March 99. I think that I just hacked out any threading at all for that
> try. The only thing that might be of more than curiosity value in it is
> a fix somewhere in the event handling code to byteswap the x,y location
> from a mouse c
Yes, Definitely! Regardless of whether or not it's got threading I'd
love to take a look at any work that's been done on the ppc. Is there
somewhere I can ftp it from? Thank you!
later,
Josh.
(Here's one of the interesting posts about threading: I think this post
was from Ulrich Weigand ([EMAIL PROTECTED]) on
Nov. 8th, 2000 - I found it out on the archive. The thread was called
"Patch to fix Solaris 7 x86 thread
support"):
>.....
> Well, it was done that way for a purpose ;-)
>
> The problem is that the higher-level thread libraries (typically
> pthreads)
> tend to make certain assumptions about things application programs
> typically
> do or don't do, and these are sometimes violated by Wine.
>
> For example, the Linux pthreads implementation assumes that all thread
> stacks must have the same size, and must reside at positions determined
> by the library. Wine doesn't like this, as it has to satify Windows
> applications' requests for variably sized thread stacks. (OK, recent
> versions of glibc also allow variably sized stacks, but only at a huge
> performance penalty.)
>
> The Solaris x86 pthreads implementation, last time I looked into it,
> assumes that it is free to create selectors in the LDT without being
> disturbed by the application. This obviously breaks with Wine, as
> Wine also thinks it can freely use the LDT without interference.
> (Note that due to a kernel bug in Solaris, this problem can quite
> reliably trigger kernel panics in certain circumstances :-/)
>
> Due to this sort of problems, we decided to do it the other way around
> and fall back to the most low-level interface to create threads on the
> platforms we support, which are direct system calls without library
> involvement. This way, we are at least sure that the threading
> library does not interfere with what Wine does.
> ....
--
Josh DuBois
654 SW Grant #103, Portland, OR 97201
503-827-4818
[EMAIL PROTECTED]
