Started playing with Wineserver on mingw/cygwin again
davidf at sjsoft.com
Wed Feb 5 02:36:59 CST 2003
David Fraser wrote:
> Dimitrie O. Paun wrote:
>> On February 1, 2003 02:10 am, David Fraser wrote:
>>> Could we go straight down to the underlying win32 api and do a
>>> GetThreadContext there? Is that cheating?
>> I don't know the Cygwin threading model, but calling the real
>> [GS]etThreadContext is a good first order approximation. If
>> interested in this task, I'd bring it up on the Cygwin mailing
> Just as a start, I tried this ... compiles fine but don't know how to
> test it ...
> Does this look right? (just done for get_thread_context)
OK, having actually thought I can see that this is not going to work.
Basically in order to do a GetThreadContext we need to get a handle to
the underlying Windows thread... what I was doing here was asking the
Wine server for a handle to the thread, then passing that to Windows.
I've now tried to look at the code to see what exactly the correspondence
between threads on Wine running on cygwin to underlying native threads
would be. (I then discovered I'd already done this previously:
I'm fairly ignorant about the code so I'd appreciate any feedback on my
From examining the code it looks to me like in Wine, "Windows" threads are
created in scheduler/sysdeps.c:SYSDEPS_SpawnThread, where there is a call to
clone which creates the thread.
"Windows" threads are initialized by sending request in the client code:
In scheduler/client.c, CLIENT_InitThread uses getpid() to determine the
unix_pid in req which then gets set on the thread in
Under cygwin, there is no clone call as far as I can make out ... there is
pthreads support and there is hackish support for fork.
Can Wine use pthreads to implement its threading?
More information about the wine-devel