Re: Interrupting GLPK on demand

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 <[email protected]> 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
>>> [email protected]
>>> https://lists.gnu.org/mailman/listinfo/help-glpk
>>>
>>
>


_______________________________________________
Help-glpk mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/help-glpk