Re: non-official updated version of glpk (4.61 pre-release)

On Mon, 2017-01-09 at 16:10 +0300, Andrew Makhorin wrote:
> > which impacts has the multi threading option on error handling?
> > 
> > Can I catch an error in the error hook and delete the environment only
> > for the relevant thread? I guess the info object will also be thread
> > specific.
> 
> Yes, glp_error_hook stores an information about registered function in a
> thread local storage, so there is no interference between threads.
> However, if a hook is not registered with glp_error_hook or if it being
> called returns to glp_error, the latter terminates the entire process
> via abort. Thus, to prevent abnormal termination of the process, the
> hook routine should terminate only its thread or perform longjmp
> assuming that due to error no glpk routines can be called any more from
> that thread (but only from that thread; this does not affect other
> threads).
> 

In principle, the hook routine may also call glp_free_env to reset the
glpk environment to an initial state and then perform longjmp. This
allows using glpk routines in the same thread; of course, all existing
glpk program objects (glp_prob, etc.) are destroyed by glp_free_env.