I agree. There is no need for a non-reentrant version of GLPK because a reentrant version will also cover non-reentrant scenarios.
A configuration option is therefore not needed.
Best regards
Heinrich
On 09.01.17, 12:52 David Monniaux <
david.monniaux@imag.fr> wrote:
Hi
> I think that running glpk in multiple threads is rather an exception
> needed mainly in interactive programs and in some other exotic
> applications, so in my opinion this option should be disabled by
> default.
I see the matter otherwise.
1) Putting this variable in thread-local storage using _Thread_local or similar costs nothing on platforms that supports it [maybe I'm wrong ?].
2) On other platforms, the configure file will simply elect not to put it in thread-local storage.
3) Linux etc. packagers generally compile packages with default options, which means that if thread-safety is required, users will have to compile their own special version of glpk instead of relying on distributed packages. This is time-consuming and error-prone (e.g. the program gets linked to one library but the dynamic linker uses another one).
4) Running glpk in multiple threads occurs when e.g. one uses OpenMP. More generally, all current machines are multicore, and a very natural way to exploit that is to run multiple threads. The alternative is to use multiple processes, which is fine when one has a number of large problems to solve but may be prohibitively costly and/or complicated if one has a large numbers of small problems to solve.
Therefore I think --enable-reentrant should be the default, with a graceful fallback to disabling it on platforms that support none of the three thread-local keywords being tested: it costs nothing and has benefits.
Regards_______________________________________________
Help-glpk mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/help-glpk