On Wed, 2008-09-24 at 11:41 -0400, 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. > > > 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.
The more complex problem is that the sipXproxy/sipXtackLib code that's actually doing all this is not designed to suspend processing of the message and come back to it later. This is a fairly extensive rework of some part of the stack (probably SipTransaction) to introduce additional state machinery. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
