Andy Spitzer wrote: > Woof! > > On Tue, 23 Sep 2008 18:28:43 -0400, Arjun Nair <[EMAIL PROTECTED]> wrote: > >> Set a hard time of 5secs for the thread to finish the query, or we >> will stop polling, kill the thread, and continue. > > I'm not sure if you really mean "kill the thread", but if you do, I > would caution that there is no safe way to stop a thread externally. > That is to say, there is no way thread "A" can stop thread "B" safely > without thread "B"'s cooperation. This has to do with locks and stuff > thread "B" may be holding at the time. POSIX threading attempted to > come up with cancellation points and all sorts of kludgy work-arounds, > but in the end they all proved unworkable. > > So if by "kill the thread" you really mean "tell the thread to stop > waiting for a result" that's okay. As the thread in question is > probably waiting on a file descriptor for a response, this can be done > either by creating a second file descriptor (via pipe or socketpair) and > using poll() in thread "B" to wait for a result on either descriptor > (this technique is used in OsServerTaskWaitable.h), or by having thread > "A" call shutdown() on the file descriptor on which thread "B" is blocking. > 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. > An alternate solution is to have the query thread do its OWN timeout of > 5 seconds waiting for a DNS response, and returning a timeout result if > no response arrives in that time. Thus the thread is in control of it's > own lifetime, and no one else need stop it. > > --Woof! > > > --Woof! 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
