Detect whether wineserver is fully started? Signal? File?

[Sebastian Lackner]

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