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 list...
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)
David
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: http://www.winehq.com/hypermail/wine-devel/2002/11/1533.html) I'm fairly ignorant about the code so I'd appreciate any feedback on my comments here. 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 server/thread.c:init_thread. 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? David