requests.{get,post} timeout

[Jon Ribbens]

On 2017-08-24, Chris Angelico <rosuav at gmail.com> wrote:
> On Fri, Aug 25, 2017 at 12:17 AM, Jon Ribbens <jon+usenet at unequivocal.eu> wrote:
>> On 2017-08-24, Chris Angelico <rosuav at gmail.com> wrote:
>>> On Thu, Aug 24, 2017 at 9:43 PM, Jon Ribbens <jon+usenet at unequivocal.eu> wrote:
>>>> Where did you explain how it can be done without help? As far as I'm
>>>> aware, you can't close the socket without help since you can't get
>>>> access to it, and as you mentioned even if you were to do so the
>>>> effect it would have on requests is completely undefined.
>>>
>>> In a single-threaded program, just hit Ctrl-C.
>>
>> By that, do you mean "kill the process"? That's obviously not
>> a sensible answer in general, especially given we were including
>> processes which have no terminal or user sitting there watching
>> them.
>
> Only in the sense that "kill" is the Unix term for "send signal".
> Python catches the signal, the system call terminates with EINTR, and
> the exception is raised. Give it a try.

Give what a try? Pressing ctrl-c? That'll kill the process.
Obviously we all agree that killing the entire process will
terminate the request and all resources associated with it.

>>> Job done. No need to know ANYTHING about the internals of the
>>> requests module, beyond that it has correct handling of signals.
>>> Want that on a clock? SIGALRM.
>>
>> Doesn't work with threading.
>
> How many of your programs have threads in them?

Um, basically all of them?

> Did you not read my point where I said that the bulk of programs can
> use these simple techniques?

I'm not sure I did but even so your point would appear to be wrong.

>> Receiving a signal is the same as closing the socket? What?
>> (And as I already mentioned, you can't close the socket anyway.)
>
> Not as such, but try it and see what actually happens. The signal
> aborts the syscall; the exception causes the stack to be unwound. TRY
> IT. It works.

Try *what*?

>> Resources not released, subsequent operations failing, the library
>> possibly left in a state from which it cannot recover. This is
>> pretty obviously stuff that "is not working". Although even then
>> you still haven't explained how we can abort the operation (even
>> with all these side-effects) in the first place.
>
> Not released UNTIL NEXT QUERY. Everything is recoverable. TRY IT. It works.

Try what?

>> It would take many orders of magnitude fewer than a billion to break
>> the program. This is not a responsible or sensible way to write a
>> computer program - to deliberately let it leak stuff and invoke
>> undefined behaviour all over the place and hope that somehow it'll
>> muddle along regardless.
>
> Leaking until the next call? A billion.

I don't believe you about it only leaking "until the next call",
whatever that means.

>>>> Basically the only way to use requests safely is to fork an individual
>>>> process for every request, which is of course spectacularly inefficient.
>>>
>>> Yes. Spectacularly inefficient and almost certainly unnecessary.
>>
>> You haven't suggested any workable alternative so far.
>
> Have you tried any of what I said?

What have you actually suggested to try?