Hm. The hanging issue there was limited to connecting to an external server. I found my issue when spawning a new game from the client ("internal" server), starting it, and immediately quitting. I don't think I tried quitting from the start page (before any kind of network connection is attempted).

For a while I've noticed that the Freeciv clients take ~2 seconds from my telling them to quit to the window actually going away, but hadn't investigated it.

Today I ended up in a situation where two users were logged in to the same machine, and one had "grabbed" the sound capability (a paused web video), such that the other user couldn't make sounds. In this situation, freeciv-gtk2 hangs indefinitely on quit (S2_3, S2_4, trunk). Adding debug narrowed the hang down to the shutdown() call in client/audio.c:audio_shutdown().

Other apps cope gracefully with this (admittedly rare) situation, so probably we can do better too.

This prompted me to investigate the area, and I found client/audio_sdl.c:my_stop() does this:

Which almost certainly explains the pause in the more common situation. Using "-P none" got rid of the pause.

I'm using the "freesounds" soundset, which has a looping "music_start", but that's not playing by the time I quit. Changing to "stdsounds" (which has no looping sounds/music), the issue is still there.

Unsorted thoughts:

• The user probably doesn't care about waiting for a nice fade-out when they've told the game to quit.
• If I quit in the pregame, when music is playing, I don't get a fade-out anyway; the music suddenly stops, then the program pauses for 2s, then quits.
• Perhaps the 2000ms wait could be conditionalised on whether there's actually something playing.