> The example t1.cs was posted in February see: > http://lists.gnu.org/archive/html/help-glpk/2008-02/msg00065.html
The glpk dynamic library name, libglpk.so, indicates that that was a GNU/Linux compilation. Under GNU/Linux (as well as under Cygwin) glpk does not use the thread local storage and stores a pointer to the library environment block in a static location. In this case the glpk library environment may be freed only with an explicitly call to glp_free_env. If glpk is compiled with a native Windows compiler like MSVC, it uses the thread local storage and frees its library environment automatically on receiving the reason DLL_THREAD_DETACH or DLL_PROCESS_DETACH passed to DllMain. This works only if: i) there is the only thread in the process; ii) once the thread has been terminated, no calls to glpk api routines are assumed, because all problem objects are automatically invalidated by glp_free_env called from DllMain. I am not sure about implementation of C++ and C# in MSVC, because I am not interested in that. However, it looks like desctructors are called *after* the thread has finished, even if it is the only thread in the process. So, if a destructor calls glp_delete_prob, it passes a pointer to a problem object, which has been invalidated by glp_free_env, that causes an error in an internal glpk routine. Since glpk api routines must not be be called from different threads, I decided just to remove DllMain feature and use a static location to keep a pointer to the glpk library environment on all platforms, including MS Windows. > when the call to glp_delete_prob in the destrutor worked fine. Maybe > glpk has changed since 4.23 so that it is no longer needed, if you are > confident that glpk always deletes it now. For the benefit of existing > code if glpk can determine when it is needed and when it isn't that would > be best. There are two ways to free memory and other resources used by glpk: either to call glp_delete_prob, which frees the memory allocated to a particular problem object, or to call glp_free_env, which frees all the memory allocated by glpk routines; in the latter case all program objects created by glpk routines become invalid. _______________________________________________ Help-glpk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-glpk
