FS#4697 - Periodic Freezing during Menu and Multiplayer Gameplay

Attached to Project: OpenTTD
Opened by Charles Pigott (LordAro) - Wednesday, 27 July 2011, 21:20 GMT
Last edited by Remko Bijker (Rubidium) - Saturday, 30 July 2011, 10:37 GMT
Type Bug
Category Core
Status Closed
Assigned To No-one
Operating System Windows
Severity High
Priority Normal
Reported Version 1.1.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Reported by MorgyN on IRC

OS: Windows 7 x64

During the Menu and during multiplayer game play, periodically the UI, Network & Gameplay would freeze, Music would continue.

Freezes would last 2-10 seconds, and would happen every 10-60 seconds.

Appears to be linked to a name resolution error of a favourited server.

If the following entry is in openttd.cfg

[servers] =

The above error occurs.
This task depends upon

Closed by  Remko Bijker (Rubidium)
Saturday, 30 July 2011, 10:37 GMT
Reason for closing:  Fixed
Additional comments about closing:  In r22695
Comment by Remko Bijker (Rubidium) - Thursday, 28 July 2011, 15:54 GMT
I cannot reproduce the game even attempting to query a server without going the multiplayer game, so how can it happen in the main menu? This under the assumption that he spoke the truth when being asked whether he was in the multiplayer window.

If he was not telling the truth and he was in the multiplayer windows, then something fishy is going on w.r.t. name resolution which should not happen at all. As far as I can see the name resolution always happens in a separate thread, so the rest of the application should run fine which the name resolution is waiting for results.
Comment by Grzegorz DuczyƄski (adf88) - Sunday, 31 July 2011, 11:51 GMT
Hi Rubidium, do you know what was causing the freeze? Why the name resolution wasn't done in a separate thread?
Comment by Remko Bijker (Rubidium) - Sunday, 31 July 2011, 19:52 GMT
Name resolution was, generally, done in a seperate thread. However, when name resolution failed the address would remain marked as unresolved and any other activity on said address would trigger another attempt to resolve it, which incidentally happened when trying to send some data which needs to take the mutex on the udp socket. Then the main thread would block trying to read the socket. Other cases are e.g. comparisions on addresses done when inserting it in the server list, which would trigger an unresolved address to be resolved (which would again fail).

So... the fix is easy: if resolution fails, mark it as resolved and don't try to resolve it later on. Only resolve it in the thread the next time you try to connect to it.