Re: Rename some signal and interrupt handling functions for consistency

On 04/03/2025 21:38, Nathan Bossart wrote:
> On Tue, Mar 04, 2025 at 08:22:02PM +0200, Heikki Linnakangas wrote:
>> To make things less confusing, the attached patch renames all the functions
>> that are part of the overall signal/interrupt handling system but are *not*
>> executed in a signal handler to e.g. ProcessSomething(), rather than
>> HandleSomething().
>
> Am I understanding correctly that your plan is to keep the "Handle" prefix
> for functions that do run in signal handlers (e.g.,
> HandleRecoveryConflictInterrupt())? I don't know how consistent the code
> is about that, but it might be nice to establish stricter guidelines for
> those, too.

Correct.

There are some completely unrelated functions that also have "Handle"
prefix, though, like HandleUploadManifestPacket() and
HandleFunctionRequest(). Ignoring those, all the remaining functions
that are in any way related to signal / interrupt handling and have the
"Handle" prefix run in signal handlers.

>> Any objections?
>
> No objections here. My only concern is that this might break some
> third-party code, especially code that uses interrupt.h. I'm not sure it's
> worth adding backward-compatibility macros, though.

I don't think it's worth fretting over. The only one of these functions
that extensions should be calling is ProcessMainLoopInterrupts(), and an
extension can easily add an compatibility #ifdef for that if they want to.

Thanks!

--
Heikki Linnakangas
Neon (https://neon.tech)