Re: [Help-glpk] Interrupting GLPK on demand

[Heinrich Schuchardt]

On 10/14/19 7:26 PM, Szabolcs Horvát wrote:
> Hello Heinrich,
>
> Thanks for the suggestion.
>
> Would this method not prevent any allocated memory from being cleaned
> up? I am not very familiar with GLPK yet, but the need for
> setjmp/longjmp suggests that any cleanup steps would be skipped.

In the error hook function you should call glp_free_env(). This will
free all memory allocated by calling GLPK functions in the current thread.

Cf.
https://sourceforge.net/p/winglpk/code/HEAD/tree/trunk/examples/c/glp_error_hook_demo.c

glpk-4.65/examples/threads/multiseed.c is an example showing error
handling for multi-threaded applications.

Best regards

Heinrich

> Best regards,
> Szabolcs
>
> On Mon, 14 Oct 2019 at 19:11, Heinrich Schuchardt <address@hidden> wrote:
> > Hello Szabolcs,
> >
> > you can create a terminal hook function (see glp_term_hook()). In this
> > hook function you can trigger an abort using glp_error(). Use a error
> > hook function (see glp_error_hook()) to catch the error and longjmp() to
> > return to the setjmp() in the calling program.
> >
> > An example in Java is available as:
> >
> > https://sourceforge.net/p/glpk-java/code/HEAD/tree/trunk/examples/java/GmplSwing.java
> >
> > An example for an error hook function in C is available as:
> >
> > https://sourceforge.net/p/winglpk/code/HEAD/tree/trunk/examples/c/glp_error_hook_demo.c
> >
> > Best regards
> >
> > Heinrich
> >
> > On 10/14/19 2:45 PM, Szabolcs Horvát wrote:
> > > Hello,
> > >
> > > Is there a way to interrupt GLPK without killing the entire process?
> > >
> > > I am interested in terminating glp_intopt(). In principle, this is
> > > possible by calling glp_ios_terminate() from the callback function
> > > passed to glp_intopt(). However, glp_intopt() will internally call
> > > glp_simplex(), which may take a very long time. Thus in practice this
> > > does not work. I could not find any way to interrupt glp_simplex() on
> > > demand.  It is possible to set a time limit (tm_lim in glp_smcp), but
> > > this is not what I need. I would like to have the ability to
> > > interactively interrupt the computation.
> > >
> > > For example, glp_simplex() could periodically call a user-supplied
> > > function. If this function returns "true", the computation should be
> > > interrupted gracefully.
> > >
> > > I do not need a partial result to be returned. I simply need a clean
> > > interruption, with the resources used by the function properly cleaned
> > > up (e.g. no unreleased memory). I assume that this is possible, since
> > > a time limit is already implemented. In principle, I could even look
> > > up the part of the code that checks the time, and add an additional
> > > interruption check. I am wondering why this wasn't implemented
> > > already, and whether simply doing this would cause any problems. Some
> > > old messages posted to this mailing list seem to suggest that
> > > implementing interruption may not be easy, which seems to be in
> > > contradiction with the fact that a time limit is already implemented.
> > > https://lists.gnu.org/archive/html/help-glpk/2006-04/msg00059.html
> > >
> > > Summary:
> > >
> > >    - Is there a way to interrupt glp_intopt() cleanly and reliably?
> > >    - If not, consider this a feature request. Please add this functionality.
> > >    - Would there be an issue with extending the time-limit check to also
> > > call a user-supplied interruption-check function?
> > >
> > > Use case:
> > >
> > > I am not very familiar with ILP solvers. I am actually using graph
> > > theory code that relies on GLPK. I am using this code from a
> > > high-level language that is typically used interactively (think Python
> > > in a Jupyter notebook). Given the nature of the problems that GLPK
> > > solves, it is very hard to predict how long a computation would take.
> > > It could be seconds or days. Therefore, it is important to be able to
> > > interrupt computations gracefully, without needing to kill the entire
> > > session.
> > >
> > > In particular, this problem came up while working on the igraph
> > > library: https://github.com/igraph/igraph/issues/897
> > >
> > > Best regards,
> > > Szabolcs
> > >
> > > _______________________________________________
> > > Help-glpk mailing list
> > > address@hidden
> > > https://lists.gnu.org/mailman/listinfo/help-glpk