Mathieu, > > I think I can solve the problem by extending the second solution > and having it backward compatible. It suffices to have > reentrant functions that take env as argument and non-reentrant > functions that takes no env argument. > > > So, we are still backward compatible but offer a reentrant > alternative. > > > Are you interested? I think it would be nice to finally address the > issue. >
Glpk is a serial code; it has no features to run in parallel. So, as I explained in my previous post, there is no sense to make it thread-safe. If it is necessary to solve several *independent* problems at the same time (for example, on a multi-core CPU), it is sufficient to run several instances of glpk as separate processes, in which case thread-safety is not needed. Replacing glp_set/get_tls with a reenterant version gives the same effect, but allows to run multiple instances of glpk within the same process that sometimes may be preferred. I think this is normal for non-interactive applications that perform numerical computations. Best regards, Andrew Makhorin _______________________________________________ Help-glpk mailing list Help-glpk@gnu.org https://lists.gnu.org/mailman/listinfo/help-glpk