[QUESTION] What's the difference between sig_on inside try: block versus sig_on_no_except?

[user202729]

Looking at the documentation, the following options appear to be functionally the same:

data = malloc(...)
try:
	sig_on()
except KeyboardInterrupt:
	free(data)
	raise

compute(data)  # function implemented in C, may take long time, we want to make this interruptable
sig_off()
free(data)

and

data = malloc(...)
if not sig_on_no_except():
	free(data)
	cython_check_exception()

compute(data)  # function implemented in C, may take long time, we want to make this interruptable
sig_off()
free(data)

and

data = malloc(...)
try:
	sig_on()
	compute(data)  # function implemented in C, may take long time, we want to make this interruptable
	sig_off()
finally:
	free(data)

Is there any difference? If not, then what's the advantage of sig_on_no_except()?

[dimpase]

In both chunks, something is off. Do you mean to catch KeyboardInterrupt in both cases? Also, malloc() doesn't throw exceptions.

[user202729]

Sorry, I don't understand what is off. (Maybe it's the free(data) in the non-error case? In that case I fixed it.)

Anyway in the both case I just want to make sure the data is freed. I immediately re-raise the interrupt afterwards.

[dimpase]

it might help to have pseudocode for what the code is meant to do

[user202729]

I already put the pseudocode in the first post.

If seeing actual code helps with your understanding more, replace malloc with mzd_init, free with mzd_free, and compute with mzd_solve_left, then the code becomes a section of PR sagemath/sage#38843 . (Specifically, case 3 are what is used in the PR).

[user202729]

I benchmarked and conclude try..finally is the fastest approach. It also leads to the cleanest code.

https://gist.github.com/user202729/52b0c7134ea34f78a4416cd19e28e578

Nevertheless, is there a point in sig_on_no_except? It's written in the documentation that

There are several more specialized functions for dealing with interrupts. As mentioned above, sig_on() makes no attempt to clean anything up (restore state or freeing memory) when an interrupt occurs. In fact, it would be impossible for sig_on() to do that. If you want to add some cleanup code, use sig_on_no_except() for this.

Did I overlook something? Or is it simply because the author of sig_on_no_except() did not think of this?