On 17.06.2017 12:20, Sebastian M. Ernst wrote:
@Bruno
Not sure if I got the problem you are describing exactly but what about doing the opposite direction? Make a very simple socket program for Windows that is launched and this program connects to your python application instead. When python notices the connection it is sure that wineserver is running because it just received the connection from an app running inside Wine. Also as long as this small utility is up wineserver won't close too.
Thanks, yes, I have considered this approach (and will likely follow it if everything else does not work). I'd prefer a "pythonic" solution without adding dependencies like a cross-compiler (for compiling the utility) to my module. I am already doing this for tests, but I'd really like to keep the module itself "clean" and easy to install. Just as a theoretical question, could such a utility be implemented as a batch file which wine (cmd) could handle "out of the box"?
@Sebastian
thanks again, this is really helpful.
If you disconnect before the real command is started the wineserver will assume it is no longer needed and terminate automatically. I would say this is a bug, because the user definitely does not expect that when passing "-p".
Is this worth opening a ticket?
I have sent a patch, lets see if it gets accepted. ;) -> https://source.winehq.org/patches/data/134955
Nevertheless, when you keep the connection open, it should actually work (and also does work for me, according to a quick test).
Once my wineserver is up, I try to do a number of path conversion using "winepath -w /some/path" etc. first before I fire up any exe-files. Am I correct in assuming that winepath should also use my wineserver (if run with the same prefix)?
Yes, it will use the same wineserver instance.
Can you check whether your quick test also works with winepath (eliminating a potential source of error)? I managed to turn winepath directly into a zombie a number of times by running winepath (too early) while wineserver was still starting. It does not produce any error messages whatsoever.
I have not been able to reproduce this problem, unfortunately. I have tested with the code which stays connected to the wineserver in order to workaround the issue above.
A slightly better solution which does not trigger this problem would be to wait for the wineserver lock (which will also appear in the server dir).
I used your code and implemented a routine which waits for the lock-file to be locked - see below this email. Usually, it requires two attempts / about 0.01 seconds until it succeeds. The PID returned by your code matches the PID of my wineserver. The problem is, just after I have confirmed the lock, winepath becomes a zombie again and again and ... occasionally, it works. Is this a bug or a lack of understanding on my part?
There is still a small race-condition (the lock is acquired but the socket has not been created yet), but Wine will be able to deal with that. It will retry a couple of times until it finally succeeds.
Could a failure in this mechanism be the reason for my zombies? (Happens with Wine 2.5, 2.6 and 2.10.)
For me it sounds like a similar problem as above, but I've also failed to reproduce this case. Of course there could be a bug somewhere in the Wine source, but I think this is rather unlikely.
Are you sure that the subprocess is not killed accidentally, for example? Or since you are using subprocess.PIPE for stdin/stdout/stderr, are the pipes maybe blocking execution of the program when they are not read periodically? For debugging purposes, you can also append '-d' to the wineserver args, which will print a message as soon as it is terminated.
Please note that if both methods work as expected, the second one has the advantage that there is no dummy connection which appears as regular process to the rest of Wine, so it would probably be preferred.
Best regards, Sebastian