Le 27/11/12 00:46, Andrew Harvey a écrit :

You could always add a function that retrieves it. I don't master this part of Boost.Thread enough to tell you if this could be enough.

Hi,

In the end I didn't really want to maintain my own Boost fork, so I came up with another solution.

The fundamental problem was that the host application, which I have no control over, was unloading my plug-in before the thread had a chance to call the pthread TSS destructor. When the thread did end, a jump to invalid memory would result.

My workaround is to ensure that the plug-in's code is never actually deallocated. I do this by finding the path of the dynamic library and re-loading it myself. Since the library is already in memory, all this does is increment its reference count by one. When the host application later unloads the plug-in, the reference count is decremented but remains non-zero.

Admittedly, it's a hack and platform-specific, but for my specific needs it works. This may be one option for people who run into similar problems.

#include <iostream>
#include <dlfcn.h>

// Not actually read or written. Just used for the symbol
static bool beacon = false;

__attribute__((constructor))
void
initialize_dso()
{
    // Get path to this library
    Dl_info thisPlugin;
    if(dladdr(&beacon, &thisPlugin))
    {
        const char* szPluginPath = thisPlugin.dli_fname;

        // Clear error code
        dlerror();

        // Increment this library's reference count by 1
        dlopen(szPluginPath, RTLD_NOW | RTLD_LOCAL);

        const char* szErr = dlerror();
        if(szErr != NULL)
        {
            std::cerr << "Error incrementing plug-in reference count. " << std::endl;
        }
    }
    else
    {
        std::cerr << "Error getting plug-in info about Kaneda. " << std::endl;
    }
}

- Andrew