libsmbclient threadsafeness

David Wuertele dave-gnus at bfnet.com
Mon Oct 18 18:15:14 GMT 2004


I'm writing a massively-threaded application that makes calls into
libsmbclient.  I have found that some of the commands are not
threadsafe, so to be conservative I'm now wrapping every call into
libsmbclient with pthread_mutex_lock().  For example:

  pthread_mutex_lock (&libsmbclient_mutex); {
    ip_list_ptr = name_query (socket_fd, star, 0, True, True, broadcast_addr, &count_tmp, &flags, NULL);
    if (ip_list_ptr != 0 && count_tmp != 0) {
      count = count_tmp;
      ip_list = (struct in_addr *) malloc (sizeof (struct in_addr) * count);
      if (ip_list!=0)
	memcpy (ip_list, ip_list_ptr, sizeof (struct in_addr) * count);
    }
    SAFE_FREE (ip_list_ptr);
  } pthread_mutex_unlock (&libsmbclient_mutex);

For the name_query command, which overwrites its ip_list data every
time it is called, I know this locking is necessary.  But for many
other commands it is not so obvious.

Before I go and code review all the libsmbclient calls for
threadsafety, is there anyone here who can tell me off the top of
their head, "hey, that one is definitely *not* threadsafe!" for the
following functions:

  cli_api()
  cli_full_connection()
  cli_lsa_close()
  cli_lsa_open_policy()
  cli_lsa_query_info_policy()
  cli_nt_session_close()
  cli_nt_session_open()
  cli_shutdown()
  cli_srvsvc_net_share_enum()
  get_ipc_connect()
  init_enum_hnd()
  load_interfaces()
  lp_load()
  lp_set_name_resolve_order()
  make_nmb_name()
  resolve_name()
  talloc_destroy()
  talloc_init()

Note: Each one of my threads creates its own socket_fd, and any return
value storage like "struct cli_state" and "ENUM_HND".  So I guess I'm
only really interested in learning about any globally shared resources
allocated inside libsmbclient for which these functions might be in
contention.

Thanks,
Dave



More information about the samba-technical mailing list