search

apolukhin / Boost.DLL

Library for comfortable work with DLL and DSO
https://boost.org/libs/dll
109 stars 69 forks source link

Check if shared_library::unload succeeded? #37

Closed eliasdaler closed 5 years ago

eliasdaler commented 6 years ago

Right now, there's no way to know if shared_library::unload succeeded or not. On Windows, this can be checked by return values of FreeLibrary. On POSIX systems, dlclose returns a non-zero value in case of error.

Is it possible to implement an optional boost::system::error_code argument for unload so it'll be possible to see what goes wrong?

apolukhin commented 6 years ago

The assumption that the shared_library::unload call always succeeds. FreeLibrary or dlclose should fail only if the handler is wrong.

@eliasdaler am I missing some point or use case?

eliasdaler commented 6 years ago

I can't really find what possible errors of FreeLibrary or dlclose can be, as they're not documented, sadly.

I've found some code from Qt base library which deals with dlclose error on QNX which caused trouble for some reason.

I've also found this StackOverflow post which says that FreeLibrary can fail if DLL throws exceptions while it's unloading. I can't test it myself now if it's always the case and what GetLastError will give me in such case.

I still think that if both FreeLibrary and dlclose can fail and provide a error code, it's worth it to let users of Boost.DLL to get it and later deal with it somehow, even if it happens incredibly rarely.

apolukhin commented 5 years ago

I'm closing this as it won't fix.

Here are my thoughts: POSIX specifies that dlclose may not unload a library and may not free other resources. Moreover, some of the C library are implemented that way. So dlclose returns success, however the function did nothing. Returning success for that case in the from shared_library::unload() is a doubtful idea.

I also failed to make a test that reproduces the error in dlclose.

So I'd rather follow the practice of some Standard Library implementations and do nothing with errors that occur only if the library usage preconditions are violated (someone corrupted the state of the object or the loaded shared library itself)