> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:help- > [EMAIL PROTECTED] On Behalf Of Antonello > Lobianco > > ...omissis... > > 'Going little bit OT.. are there any plan to make glpk at least > reendrant?? I > need to solve several independent small problems, and I don't know if I > can > spread them in several threads...
I didn't participate to coding the GLPK library, so I may easily be wrong. However, it seems to me that its non-reentrancy is only due to the LIBENV structure (see glplib.h), which is shared among more problems. This holding, one way to make the GLPK library more re-entrant is to define your own version of the lib_set_ptr() and lib_get_ptr() functions, such that they store and return a pointer to a thread-local LIBENV structure. This holds as long as you build, solve and destroy a problem in the same thread. I mean, you can start many threads, but each one have to build, solve and destroy its own problems. It would be dangerous to build a problem in a thread and solve or destroy it in another since, in example, the GLPK's memory allocation code uses the mem_ptr member of the LIBENV struct to manage memory allocation. You could, however, overcame also this limit by providing your own, thread-safe versions of the umalloc, ucalloc and ufree functions. In most thread-supporting environments, you simply have to use the malloc, calloc and free functions supplied by the environment itself: they are already thread-safe and this way the GLPK library would not rely anymore on the LIBENV struct for memory allocation. Regards, Giampaolo > > Thanks, > Antonello > > > _______________________________________________ > Help-glpk mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/help-glpk _______________________________________________ Help-glpk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-glpk
