Josh DuBois wrote:
> 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.
The pthreads documentation seems to suggest that the stack size
should be controllable through the pthread_attr_setstacksize() API.
Searching on google reveals that the LinuxThreads 0.8 FAQ states:
E.5: Does LinuxThreads implement pthread_attr_setstacksize() and
pthread_attr_setstackaddr()?
These optional functions are provided in recent versions of
LinuxThreads (0.8 and up). Earlier releases did not provide these
optional components of the POSIX standard.
Even if pthread_attr_setstacksize() and pthread_attr_setstackaddr()
are now provided, we still recommend that you do not use them
unless you really have strong reasons for doing so. The default
stack allocation strategy for LinuxThreads is nearly optimal: stacks
start small (4k) and automatically grow on demand to a fairly large
limit (2M). Moreover, there is no portable way to estimate the stack
requirements of a thread, so setting the stack size yourself makes
your program less reliable and non-portable.
Which seems like a reasonable argument. I don't have too much Win32
source around now that uses threads heavily, but especially if we're
talking about source-build winelib apps, I find it hard to believe that
setting the thread stack size is really a showstopper for most apps.
> Can pthreads in fact be used on linuxppc?
Undoubtedly. Lots of stuff would break without them.
> > 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!
Ok. The tarball is up on: http://www.transgaming.com/wineppc_old.tar.gz
It will stay up there for a few days only (the server is currently my
home ADSL box, but will be switching soon to a real ISP).
The tarball is based off of wine-990226.
The byte-swapping fix I mentioned appears to have just fixed something else
that I probably introduced myself. The weirdness is in winpos.c, where it
generates an NCHITTEST message: when this was processed by the DefWndProc
it was splitting the high word and the low word in the wrong order. Since
the DefWndProc code for this in my old PPC version appears to be a bit
different from what the CVS tree has for that time (Mar 99), I have to
conclude that it's something I broke in the DefWndProc, then hacked around
in winpos. IE: Probably best to ignore it.
The other bit of code that might be useful in it is the wrc code that
generates asm for registering the resources. On the resource front,
my recollection is that resource data is stored in big-endian format,
converted in wrc - but only simple resources have automatic conversion.
Things like icons and BMPs don't translate properly yet.
The only app that I remember running on it is the clock sample.
> (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"):
>
> > 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 :-/)
LDTs are of course not an issue on PPC.
> > 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.
Not a bad strategy in general, but in the specific case of LinuxPPC, I
think that the appropriate level might well be pthreads. On MacOS X,
I have no idea what other low level interfaces might be available.
-Gav
--
Gavriel State
CEO
TransGaming Technologies Inc.
[EMAIL PROTECTED]
