Hacker News new | past | comments | ask | show | jobs | submit login

The most common reason to want this is for long running programs with a plug-in architecture. Here’s my advice, for use cases where the plug-in and the plug-in loader are both under your control:

1. Don’t directly dlopen the .so file. Copy it to a temporary file and dlopen that. Much fewer headaches that way when the original .so file changes. Bonus points for using Linux’s memfd or FreeBSD’s SHM_ANON.

2. Rely as little on global/thread-local state as possible in the plug-in. Minimize the use of non-reentrant function calls in exported functions.

3. Don’t use musl. Its dlclose is a no-op and will cause memory leaks.

4. If the plug-in is to be accessed across multiple threads, copy the symbols you’ll need from the plug-in into a struct, and maintain a reference count alongside the struct. When reloading the plug-in, create a new struct for all new threads to use, and free the old struct when its reference count goes to zero.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: