On UNIX, the initial socket connection can be synchronous (that is, no trial connection any more, but it is guaranteed to make successful connection at the first "connect").
See the patch D510: Connection to gpg-agent/dirmngr/etc., which was applied to master. For Windows, it keeps old code.
By making it synchronous, we can remove a race condition. It matters only in heavy loads, but it occurs, like the case of Debian buildd.
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | • gniibe | T5109 Initial socket connection to server | ||
| Resolved | • gniibe | T5884 dotlock is not perfect (errornously remove .lock as stale lockfile) |
I had overlooked this fix rG044379772fc5: common: Fix the previous commit., after the commit of rGb1c56cf9e2bb: common: Use gnupg_spawn_process_fd to invoke gpg-agent/dirmngr..
So, the synchronous initial connection is only for UNIX.
Frankly, I do not like this change - in particulalr not for the stable branch. Having a timeout on connections is actually a Good Thing and better than to wait indefinitely. There is a high risk on regressions and that is not acceptable for the stable branch. The branch already had a couple of regressions in 2.2.2x and we need to fix them and not introduce others.
We use a locking scheme to make sure that only one process starts a daemon and that works very well. Before we go further here - and for sure only on master - I would like to have a complete analysis of the pros and cons including rare cases like old overloaded Sparc boxes in supervised and standard mode.
For the Debian problem it might be better to use "gpgconf --launch" and we add an option here to wait for the daemon to be started. That can be implemented in gpg-connect-agent which then should get the same option.