http://bugs.winehq.org/show_bug.cgi?id=17195
--- Comment #46 from Luke Kenneth Casson Leighton lkcl@lkcl.net 2011-12-19 07:11:26 CST --- sorry adam it's been a while, but if that's a value of 0x3 then yes it's quite likely to be the case.
the order in which the work really needs to be done is:
* create ncalrpc which is identical functionality to existing *broken* NamedPipes * prove that test cases work by using broken and completely unacceptable method of use of socket pairs, use of which would otherwise result in wine being classed as a security violation [resource starvation] * decide what to do from here:
path 1)
* decide that it's perfectly acceptable to create complete, total, utter reimplementations of all services when the time comes to tackle these things - all services which *could* be "farmed out" into userspace are instead forcibly implemented as wine-equivalent to kernelspace i.e. asynchronous. this will be hundreds of thousands of lines of code.
path 2)
* add kernel-level multithreading to wineserver. it involves insertion of global locks around data structures that have, until now, not been necessary. basically the entire wineserver codebase needs to be properly made multithreaded.
* then write that proper "shim" which allows redirection of kernelspace pipe data out to userspace, allowing individual kernel-level threads to "block" until the *userspace* program feeds back the response.
i don't want to discourage you from working on this adam but this really is a "bite the bullet and get on with it" point for the wine team.
of course, i am not a wine team member, nor have i yet received the offers of payment which would allow me to help do the required work, so i have to leave it to the wine team members to decide whether it is more useful to them to continue with the situation as-is or whether it is more useful for them to evaluate and take the advice above.