When running the nonce-tcp and tcp-anonymous tests in one run
of gdbus-peer, or running one of them twice via command-line options
"-p /gdbus/tcp-anonymous -p /gdbus/tcp-anonymous", the one run second
would sometimes fail to connect with ECONNRESET.

Adding more debug messages revealed that in the successful case,
g_main_loop_run() was executed in the server thread first:

# tcp-anonymous: server thread: listening on tcp:host=localhost,port=53517
# tcp-anonymous: server thread: starting server...
# tcp-anonymous: server thread: creating main loop...
# tcp-anonymous: server thread: running main loop...
# tcp-anonymous: main thread: trying tcp:host=localhost,port=53517...
# tcp-anonymous: main thread: waiting for server thread...

but in the failing case, the main thread attempted to connect
before the call to g_main_loop_run() in the server thread:

# tcp-anonymous: server thread: listening on tcp:host=localhost,port=40659
# tcp-anonymous: server thread: starting server...
# tcp-anonymous: server thread: creating main loop...
# tcp-anonymous: main thread: trying tcp:host=localhost,port=40659...
# tcp-anonymous: server thread: running main loop...

(The log message "creating main loop" was immediately before
create_service_loop(), and "running main loop" was immediately
before g_main_loop_run().)

To ensure that the GDBusServer has a chance to start accepting
connections before the main thread tries to connect to it, do not
tell the main thread about the service_loop immediately, but instead
defer it to an idle.

---

On the particular OS I'm looking at right now, this failed reasonably reliably on i386 virtual machines, but passed reliably on ARM and x86-64. I don't know why... the patch fixes a race condition and seems to solve it, so perhaps the fact that i386 is register-starved changed its performance characteristics enough to make the failure occur?