loader: On Mac, reserve the process's original thread for the frameworks.
ken at codeweavers.com
Wed Oct 27 19:34:27 CDT 2010
On Oct 27, 2010, at 5:36 PM, Ken Thomases wrote:
> The frameworks expect the original thread to run its run loop, so input
> sources (like distributed notifications) get processed. For example,
> Core Audio on Snow Leopard doesn't track changes in the default ouput
> device, such as when headphones are plugged in, without this.
> libs/wine/Makefile.in | 2 +-
> libs/wine/loader.c | 114 +++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 115 insertions(+), 1 deletions(-)
Hold off on this one. I've encountered a strange issue after sending it (that I didn't encounter in earlier testing).
err:process:start_wineboot failed to start wineboot, err 1359
Apparently, there's a failure of an execve() system call in a child process. It's getting EFAULT.
Artificially avoiding the very top of the available address space for the secondary thread stack works around the problem. Either the fork() alters the address space (perhaps as a consequence of eliminating all but one thread when creating the child from the parent), or execve() is sensitive to the specific layout. Perhaps it needs to use the very top of the address space, but won't if it thinks that's where the thread's stack is. Or something.
More information about the wine-devel