On 12/18/2015 12:09 PM, Andrew Johnson wrote:
> I haven't looked at the code, but shouldn't this be fixed in the
> ipAddrToAsciiEnginePrivate class destructor, such that it *doesn't* wait
> for the thread to exit but somehow leaves an indication that if/when
> gethostbyaddr() ever returns that it must clean up by itself and exit?
That's what I'm looking into. The first problem is understanding this oh so complicated API...
The issue as I see it is to allow a "transaction" to be aborted while a lookup is in progress.
Not stopping the thread is easy. Just remove the reference count so that, once started, it runs until process termination.
...
> In any case I would be happy to see patches for the CAref documentation
> and the AppDevGuide that explain what's happening when
> ca_context_destroy() is slow to return.
I'm for marking this API as deprecated for external use in preparation for replacing it.
On 12/18/2015 12:09 PM, Andrew Johnson wrote: ginePrivate class destructor, such that it *doesn't* wait
> I haven't looked at the code, but shouldn't this be fixed in the
> ipAddrToAsciiEn
> for the thread to exit but somehow leaves an indication that if/when
> gethostbyaddr() ever returns that it must clean up by itself and exit?
That's what I'm looking into. The first problem is understanding this oh so complicated API...
The issue as I see it is to allow a "transaction" to be aborted while a lookup is in progress.
Not stopping the thread is easy. Just remove the reference count so that, once started, it runs until process termination.
... destroy( ) is slow to return.
> In any case I would be happy to see patches for the CAref documentation
> and the AppDevGuide that explain what's happening when
> ca_context_
I'm for marking this API as deprecated for external use in preparation for replacing it.