Hello Joey, your patch indicates some of the code regions that are not reentrant.
(The xmalloc and xfree function offer the possibility to hunt down memory leaks and have been quite valuable in development of GLPK.) If GLPK would only address POSIX systems the library pthread could be used to create the necessary locks to make the code reentrant. An idea is given in http://www.megacoder.com/files/presentation/Thread-Safe_Programming.pdf Thread-Safe Programming Including a library like http://openmp.org/wp/ OpenMP would allow creating code that is both threadsafe and easy to compile on diverse systems. OpenMP is available with GCC, VisualStudio 2008 and other compilers: http://openmp.org/wp/openmp-compilers/ OpenMP Compilers Best regards Xypron Rios, Joseph L. (ARC-AFO) wrote: > > Andrew may want to avert his eyes... it isn't pretty, but it > works. Basically you replace GLPK's memory management with regular > malloc() > and free() calls within glplib07.c and then you make a couple of hacks in > glplib10.c. I left all of the original lines as comments to better see > the > changes. If anyone tries this, please verify that the patch works as > advertised as I may have forgotten some other change I made. Oh, my > changes > were based on 4.28 I think. > > -- View this message in context: http://www.nabble.com/GLPK-re-endrant-tp24256046p24295635.html Sent from the Gnu - GLPK - Help mailing list archive at Nabble.com. _______________________________________________ Help-glpk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-glpk
