bug#35506: 27.0.50; Emacs hangs while interrupting tramp processes

[John Shahid]

Michael Albinus <michael.albinus@gmx.de> writes:

> John Shahid <jvshahid@gmail.com> writes:
>
> Hi John,

[...]

> Reading the Emacs manual again at (info "(elisp) Signals to Processes")
>
> --8<---------------cut here---------------start------------->8---
> If CURRENT-GROUP is ‘nil’, the signal is sent to the process group of
> the immediate subprocess of Emacs.
> --8<---------------cut here---------------end--------------->8---
>
> So your patch is correct, pls push.

Thanks for reviewing the patch.  Unfortunately, I don't have push access
to the repository.  Do you mind pushing the patch for me?

[...]

> No, Tramp must report success. See the Emacs manual, same location as
> above:
>
> --8<---------------cut here---------------start------------->8---
>  -- Variable: interrupt-process-functions
>      This variable is a list of functions to be called for
>      ‘interrupt-process’.  The arguments of the functions are the same
>      as for ‘interrupt-process’.  These functions are called in the
>      order of the list, until one of them returns non-‘nil’.  The
>      default function, which shall always be the last in this list, is
>      ‘internal-default-interrupt-process’.
>
>      This is the mechanism, how Tramp implements ‘interrupt-process’.
> --8<---------------cut here---------------end--------------->8---

I just realized that I made an unintentional change.  I got rid of the
return value, so the function will always return nil causing
`interrupt-process' to fallback to the default implementation.  That was
not my intention.  I think what I meant to do is to:

1. Asynchronously kill the process (the first patch)
2. Always return success, e.g. return proc.

It doesn't make sense to use the default interrupt function for remote
processes anyway, so always succeeding seems like the right thing to do
here.  This begs the question, why do we have to wait for the process
output at all?

> So we must investigate, why `interrupt-process' does not return in
> your case.

That is a good point.  I didn't look deeply into why the `with-timeout'
isn't timing out in my case.  I will try to understand what is going on
in the next few days.

> Best regards, Michael.
>
> PS: In the FSF list, your email address is given as <vshahid@gmail.com>.
> Looks like a typo, maybe you contact the FSF clerk about.

Thanks for letting me know.  No one brought this up before.  I will
follow up with the FSF clerk.

Cheers,

JS