mirror of
git://git.gnupg.org/gnupg.git
synced 2025-01-02 12:01:32 +01:00
dirmngr: Lazily launch ldap reaper thread.
* dirmngr/dirmngr.c (main): Avoid calling ldap_wrapper_launch_thread() Before we need it. * dirmngr/ldap-wrapper.c (ldap_wrapper): Call ldap_wrapper_launch_thread() just in time (before any attempt to use an ldap subprocess). -- A dirmngr process that never looks anything up in LDAP has no need for a reaper thread, but one was started automatically. This thread wakes up every two seconds to look for ldap processes that might never have been running. We won't start more than one reaper thread for any given dirmngr due to the static int "done" in ldap_wrapper_launch_thread(), so it's safe to call this every time there is a use of ldap_wrapper. If someone wants to do further dirmngr optimizations for ldap users, the reaper thread itself could use dynamically-calculated timeouts (and probably needs to be alerted dynamically when a new ldap subprocess is available so it can re-calculate those timeouts). Note: It's not clear to me how to test ldap access effectively; i know of no public ldap services that i can verify against, and i do not run my own ldap servers. If someone has a publicly-available ldap server that developers can run tests against, i would be happy to hear about it. Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
This commit is contained in:
parent
ecc126a7ce
commit
f6728d13e8
@ -989,9 +989,6 @@ main (int argc, char **argv)
|
||||
thread_init ();
|
||||
cert_cache_init ();
|
||||
crl_cache_init ();
|
||||
#if USE_LDAP
|
||||
ldap_wrapper_launch_thread ();
|
||||
#endif /*USE_LDAP*/
|
||||
http_register_netactivity_cb (netactivity_action);
|
||||
start_command_handler (ASSUAN_INVALID_FD);
|
||||
shutdown_reaper ();
|
||||
@ -1027,9 +1024,6 @@ main (int argc, char **argv)
|
||||
thread_init ();
|
||||
cert_cache_init ();
|
||||
crl_cache_init ();
|
||||
#if USE_LDAP
|
||||
ldap_wrapper_launch_thread ();
|
||||
#endif /*USE_LDAP*/
|
||||
http_register_netactivity_cb (netactivity_action);
|
||||
handle_connections (3);
|
||||
assuan_sock_close (3);
|
||||
@ -1238,9 +1232,6 @@ main (int argc, char **argv)
|
||||
thread_init ();
|
||||
cert_cache_init ();
|
||||
crl_cache_init ();
|
||||
#if USE_LDAP
|
||||
ldap_wrapper_launch_thread ();
|
||||
#endif /*USE_LDAP*/
|
||||
http_register_netactivity_cb (netactivity_action);
|
||||
handle_connections (fd);
|
||||
assuan_sock_close (fd);
|
||||
@ -1251,9 +1242,6 @@ main (int argc, char **argv)
|
||||
/* Just list the CRL cache and exit. */
|
||||
if (argc)
|
||||
wrong_args ("--list-crls");
|
||||
#if USE_LDAP
|
||||
ldap_wrapper_launch_thread ();
|
||||
#endif /*USE_LDAP*/
|
||||
crl_cache_init ();
|
||||
crl_cache_list (es_stdout);
|
||||
}
|
||||
@ -1267,9 +1255,6 @@ main (int argc, char **argv)
|
||||
thread_init ();
|
||||
cert_cache_init ();
|
||||
crl_cache_init ();
|
||||
#if USE_LDAP
|
||||
ldap_wrapper_launch_thread ();
|
||||
#endif /*USE_LDAP*/
|
||||
if (!argc)
|
||||
rc = crl_cache_load (&ctrlbuf, NULL);
|
||||
else
|
||||
@ -1293,9 +1278,6 @@ main (int argc, char **argv)
|
||||
thread_init ();
|
||||
cert_cache_init ();
|
||||
crl_cache_init ();
|
||||
#if USE_LDAP
|
||||
ldap_wrapper_launch_thread ();
|
||||
#endif /*USE_LDAP*/
|
||||
rc = crl_fetch (&ctrlbuf, argv[0], &reader);
|
||||
if (rc)
|
||||
log_error (_("fetching CRL from '%s' failed: %s\n"),
|
||||
|
@ -654,8 +654,9 @@ ldap_wrapper (ctrl_t ctrl, ksba_reader_t *reader, const char *argv[])
|
||||
only viable solutions are either to have another thread
|
||||
responsible for logging the messages or to add an option to the
|
||||
wrapper module to do the logging on its own. Given that we anyway
|
||||
need a way to rip the child process and this is best done using a
|
||||
general ripping thread, that thread can do the logging too. */
|
||||
need a way to reap the child process and this is best done using a
|
||||
general reaping thread, that thread can do the logging too. */
|
||||
ldap_wrapper_launch_thread ();
|
||||
|
||||
*reader = NULL;
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user