So far, our implementation does a bit awkward way to monitor socket takeover.
It is rather simpler to have a thread monitoring the takeover with a loop by the interval of CHECK_OWN_SOCKET_INTERVAL.
| rG GnuPG | |||
| rG28364affa64e agent: Fix sock_inotify_fd handling. | |||
| rG76896e2339a4 agent: Recover support CHECK_OWN_SOCKET_INTERVAL == 0. | |||
| rGb2826924eeca agent: Fix the handling of socket takeover. | |||
| rG95186ae92f92 agent: Use a thread to monitor socket takeover. | |||
FWIW: These days a thread on Linux is not that costly but nevertheless takes up resources. On other Unices (and WindowsCE) threads have quite some overhead and that was the reason I implemented it the way it was.
I see the reason.
These days, having a thread (or more) is OK for memory resource wise. Creating a thread may be still costly for execution resources. Once created and keep using the one makes sense.
This case of gpg-agent is a fallback (when inotify doesn't work or when gpg-agent is invoked as a child process). There is no monitoring thread usually.
For master, I'll look into dirmngr and keyboxd, which have similar code.