RE: [Help-glpk] Compilation problems on RH Enterprice...

[Giampaolo Tomassoni]

> -----Original Message-----
> From: address@hidden [mailto:help-
> address@hidden 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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/help-glpk