Hi @akihikodaki , thanks for this. Your main point here is sound, given that signal.default_int_handler() requires the two arguments (or a TypeError: default_int_handler expected 2 arguments, got 0 will be given).

I'm curious about how you found this problem (which has existed for a whooping 8 years, since 56e649e).

A curious fact is that in the actual implementation of default_int_handler() (in cpython at least), it looks like the arguments are not used at all:

static PyObject *
signal_default_int_handler_impl(PyObject *module, int signalnum,
                                PyObject *frame)
/*[clinic end generated code: output=bb11c2eb115ace4e input=efcd4a56a207acfd]*/
{
    PyErr_SetNone(PyExc_KeyboardInterrupt);
    return NULL;
}

Finally, any reasons for actually maintaining the signum and frame argument names? I find that it's best for readability purposes, and there's no need for more than those two arguments.

@clebergnu It looks like Python changed its behavior with version 3.10.0: python/cpython#21197

Finally, any reasons for actually maintaining the signum and frame argument names? I find that it's best for readability purposes, and there's no need for more than those two arguments.

You mean not maintaining them? I thought it clarifies Avocado does not care the arguments and it is just passing through. It will be also immune to an API change which adds a new argument to the signal handler. However, sometimes you may want to know the exact expected argument by looking at the header of signal_handler method as you say. It's matter of preference so I'll amend this change accordingly if you prefer maintaining them.

@clebergnu It looks like Python changed its behavior with version 3.10.0: python/cpython#21197

Finally, any reasons for actually maintaining the signum and frame argument names? I find that it's best for readability purposes, and there's no need for more than those two arguments.

You mean not maintaining them? I thought it clarifies Avocado does not care the arguments and it is just passing through. It will be also immune to an API change which adds a new argument to the signal handler. However, sometimes you may want to know the exact expected argument by looking at the header of signal_handler method as you say. It's matter of preference so I'll amend this change accordingly if you prefer maintaining them.

Yes, I meant not maintaining them. But, I did not have the context about the change in function signature between versions (thanks for the explanation). In the end, because we need to support a wide range of Python versions, your original/current proposal is better indeed.

I'm trying to understand the CI failures with jobs getting stuck, though.

Hi @akihikodaki, I've merged a rebased version from #5540. Thanks!