Hi all,
I have been following for a few months now the recent glibc and nptl changes. How glibc now eliminated it's own version of wineserver in it's thread implementation with nptl. I have also read up on the difficulties the mono people have with linking to wine due to pthreads. I am a gentoo developer with some spare time. I recently came across your pending problem when we put glibc-2.3.2-pre1 into our unstable branch. I have read up on some of the wine-devel email archives. I have a machine setup with the 2.5 kernel and nptl to do some wine development on! I have also noticed the winex problems outlined at http://www.transgaming.com/papers/shmserver.html
I figured a proper solution to the wine thread thing would also for the most part solve that problem also as most wineserver calls like mutexes, thread signalling which take up the CPU time can be migrated to glibc and thus the new 2.5 kernel by using futexes and the new thread syscalls and tls. This is especially true after I read the functions in scheduler/client.c, reading / writing to a pipe per syscall! I am not that experienced a developer, but I am useful. I have started reading up the wine source code and understand basics of the wineserver message passing and the TEB / tls system. I know little about windows programming though. Any hint on what I can work on, help, to get this working again?
My idea is to alter wine so that it runs on any 100% ish POSIX threading system, aka glibc, and thus offload many tasks to the system library and solve the difficulties for good. This may be difficult / impossible esp. for windows only syscalls, but for those the Winex shm idea may work, with minimal errno hacking. (as the errno can be set by the calling thread ). Any ideas where I can start ?
Stefan