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