On 2017-08-24, Chris Angelico <ros...@gmail.com> wrote: > On Fri, Aug 25, 2017 at 12:17 AM, Jon Ribbens <jon+use...@unequivocal.eu> > wrote: >> On 2017-08-24, Chris Angelico <ros...@gmail.com> wrote: >>> On Thu, Aug 24, 2017 at 9:43 PM, Jon Ribbens <jon+use...@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? -- https://mail.python.org/mailman/listinfo/python-list
