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(-)
<0001-loader-On-Mac-reserve-the-process-s-original-thread-.patch>
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.
-Ken
Ken Thomases ken@codeweavers.com writes:
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.
Probably unrelated, but note that in Mac OS until recently, execve failed if there was more than one thread. That's going to break the process startup.
-
Alexandre Julliard -
Ken Thomases