Re: Patch proposal: New hooks in the connection path

Hi,

On 8/16/22 10:10 AM, Bharath Rupireddy wrote:
> On Tue, Aug 16, 2022 at 1:31 PM Drouvot, Bertrand <bdrouvot(at)amazon(dot)com> wrote:
>> On 8/14/22 7:52 AM, Gurjeet Singh wrote:
>>> On Mon, Aug 8, 2022 at 3:51 AM Drouvot, Bertrand <bdrouvot(at)amazon(dot)com> wrote:
>>> I think we can reduce the number of places the hook is called, if we
>>> call the hook from proc_exit(), and at all the other places we simply set
>>> a global variable to signify the reason for the failure. The case of
>>> _exit(1) from the signal-handler cannot use such a mechanism, but I
>>> think all the other cases of interest can simply register one of the
>>> FCET_* values, and let the call from proc_exit() pass that value
>>> to the hook.
>> That looks like a good idea to me. I'm tempted to rewrite the patch that
>> way (and addressing the first comment in the same time).
>>
>> Curious to hear about others hackers thoughts too.
> IMO, calling the hook from proc_exit() is not a good design as
> proc_exit() is a generic code called from many places in the source
> code, even the simple code of kind if(call_failed_conn_hook) {
> falied_conn_hook(params);} can come in the way of many exit code paths
> which is undesirable, and the likelihood of introducing new bugs may
> increase.

Thanks for the feedback.

What do you think about calling the hook only if the new global variable
is not equal to its default value (which would mean don't trigger the
hook)?

Regards,

--
Bertrand Drouvot
Amazon Web Services: https://aws.amazon.com