bug#34607: url-retrieve-synchronously: TIMEOUT option value takes no effect

bug#34607: url-retrieve-synchronously: TIMEOUT option value takes no effect

[Bad Blue Bull]

[-- Attachment #1: Type: text/html, Size: 880 bytes --]

bug#34607: url-retrieve-synchronously: TIMEOUT option value takes no effect

[Bad Blue Bull]

[-- Attachment #1: Type: text/html, Size: 552 bytes --]

bug#34607: (no subject)

[Bad Blue Bull]

[-- Attachment #1: Type: text/html, Size: 231 bytes --]

bug#34607: (no subject)

[Lars Ingebrigtsen]

Bad Blue Bull <ibmbull@yandex.ru> writes:

> sorry, elisp line intented intended to be
> (with-current-buffer (url-retrieve-synchronously "http://gnu.org" nil t 3) (kill-buffer))

This is surprisingly difficult to fix -- the reason being that URL
library is asynchronously following a redirect, and possibly opening a
new connection, and then marking that new connection with
`process-query-on-exit-flag'.  So depending on where you are in that
cycle, the buffer may have a query-enabled process when you try to kill
it.

Which sucks.

On timeouts, url-retrive-synchronously should abort the entire thing,
but url-retrieve (which is used in the background) doesn't really
support that...

Hm.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#34607: (no subject)

[Dmitry Gutov]

On 15.05.2019 7:08, Lars Ingebrigtsen wrote:
> On timeouts, url-retrive-synchronously should abort the entire thing,
> but url-retrieve (which is used in the background) doesn't really
> support that...

I think that's one of the reasons behind url-retrieve-synchronously's 
two delete-process calls. They don't exactly seem to work as intended, 
though.

bug#34607: (no subject)

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 15.05.2019 7:08, Lars Ingebrigtsen wrote:
>> On timeouts, url-retrive-synchronously should abort the entire thing,
>> but url-retrieve (which is used in the background) doesn't really
>> support that...
>
> I think that's one of the reasons behind url-retrieve-synchronously's
> two delete-process calls. They don't exactly seem to work as intended, 
> though.

Yeah, they don't trigger on timeouts, apparently.

I've now added some more process deletions, which fixes this use case:

(with-current-buffer (url-retrieve-synchronously "http://gnu.org" nil t  0.1)
  (kill-buffer))

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#34607: (no subject)

[Dmitry Gutov]

On 19.07.2020 23:42, Lars Ingebrigtsen wrote:
> Yeah, they don't trigger on timeouts, apparently.

Thanks!

> I've now added some more process deletions, which fixes this use case:
> 
> (with-current-buffer (url-retrieve-synchronously"http://gnu.org"  nil t  0.1)
>    (kill-buffer))

That's a neat little way to reproduce the problem. Might be worth it to 
add a test like this.

bug#34607: (no subject)

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

>> I've now added some more process deletions, which fixes this use case:
>> (with-current-buffer (url-retrieve-synchronously"http://gnu.org"
>> nil t  0.1)
>>    (kill-buffer))
>
> That's a neat little way to reproduce the problem. Might be worth it
> to add a test like this.

For a non-automatic test?  I don't think we want to hit that web site
during the normal tests.  :-)

But it's brittle in any case -- it's a good test site now because it
uses a redirect, but that may not be the case in the future, so I don't
know how useful it is as a test in the long term...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no