Arjun Nair wrote: > Kill might have been too strong of a word here. I was envisioning maybe using > OsServerTasks - handleMessage(), and postMessage(). So when the timeout > happens, I post "OsMsg::OS_SHUTDOWN" to the thread and move on. After > completing the query, the thread would clean itself up. > > However, I think I might have jumped the gun on this. The resolver routines > are not thread safe (at least from the comments in the code). Digging deeper, > it seems that the "libresolv" library was formerly not thread-safe, but in > the newer versions, it is "more" thread-safe, but not yet fully (thread-safe > if you don't use it in certain ways). We should look into using another lib > for the resolver. >
FYI http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/resolv/README?cvsroot=glibc Using the resolver in multi-threaded code ========================================= The traditional resolver interfaces `res_query', `res_search', `res_mkquery', `res_send' and `res_init', used a static (global) resolver state stored in the `_res' structure. Therefore, these interfaces are not thread-safe. Therefore, BIND 8.2 introduced a set of "new" interfaces `res_nquery', `res_nsearch', `res_nmkquery', `res_nsend' and `res_ninit' that take a `res_state' as their first argument, so you can use a per-thread resolver state. In glibc, when you link with -lpthread, such a per-thread resolver state is already present. It can be accessed using `_res', which has been redefined as a macro, in a similar way to what has been done for the `errno' and `h_errno' variables. This per-thread resolver state is also used for the `gethostby*' family of functions, which means that for example `gethostbyname_r' is now fully thread-safe and re-entrant. The traditional resolver interfaces however, continue to use a single resolver state and are therefore still thread-unsafe. The resolver state is the same resolver state that is used for the initial ("main") thread. Arjun _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
