On 2017-08-25, Chris Angelico wrote:
> On Sat, Aug 26, 2017 at 6:16 AM, Jon Ribbens
> wrote:
>> I said it in the majority of the posts I've made in this thread.
>> I said it in the post you were responding to just now. I'm using
>> threads. Now I've said it again.
>
> You said WHY you are using
On Sat, Aug 26, 2017 at 6:16 AM, Jon Ribbens wrote:
> On 2017-08-25, Chris Angelico wrote:
>> On Sat, Aug 26, 2017 at 5:40 AM, Jon Ribbens
>> wrote:
>>> On 2017-08-25, Chris Angelico wrote:
On Sat, Aug 26, 2017 at 1:47 AM, Jon Ribbens
wrote:
> On 2017-08-25, Chris Angelico wro
On 2017-08-25, Chris Angelico wrote:
> On Sat, Aug 26, 2017 at 5:40 AM, Jon Ribbens
> wrote:
>> On 2017-08-25, Chris Angelico wrote:
>>> On Sat, Aug 26, 2017 at 1:47 AM, Jon Ribbens
>>> wrote:
On 2017-08-25, Chris Angelico wrote:
> That looks like an exception to me. Not a "process
On Sat, Aug 26, 2017 at 5:40 AM, Jon Ribbens wrote:
> On 2017-08-25, Chris Angelico wrote:
>> On Sat, Aug 26, 2017 at 1:47 AM, Jon Ribbens
>> wrote:
>>> On 2017-08-25, Chris Angelico wrote:
That looks like an exception to me. Not a "process is now terminated".
That's what happened wh
On 2017-08-25, Chris Angelico wrote:
> On Sat, Aug 26, 2017 at 1:47 AM, Jon Ribbens
> wrote:
>> On 2017-08-25, Chris Angelico wrote:
>>> That looks like an exception to me. Not a "process is now terminated".
>>> That's what happened when I pressed Ctrl-C (the IP address was
>>> deliberately pic
On Sat, Aug 26, 2017 at 1:47 AM, Jon Ribbens wrote:
> On 2017-08-25, Chris Angelico wrote:
>> That looks like an exception to me. Not a "process is now terminated".
>> That's what happened when I pressed Ctrl-C (the IP address was
>> deliberately picked as one that doesn't currently exist on my n
On 2017-08-25, dieter wrote:
> This may no longer work. Long ago, I have often been plagued
> by such EINTR exceptions, and I have wished heavily that in those
> cases the IO operation should be automatically resumed. In recent time,
> I have no longer seen such exceptions - and I concluded that m
On 2017-08-25, Chris Angelico wrote:
> That looks like an exception to me. Not a "process is now terminated".
> That's what happened when I pressed Ctrl-C (the IP address was
> deliberately picked as one that doesn't currently exist on my network,
> so it took time).
Ok yes, so ctrl-C is sending
Chris Angelico writes:
> ...
> That looks like an exception to me. Not a "process is now terminated".
> That's what happened when I pressed Ctrl-C (the IP address was
> deliberately picked as one that doesn't currently exist on my network,
> so it took time).
What Jon argues about: signals are de
Jon Ribbens writes:
> On 2017-08-24, Chris Angelico wrote:
>> On Thu, Aug 24, 2017 at 9:43 PM, Jon Ribbens
>> 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 ment
On Fri, Aug 25, 2017 at 10:42 AM, Jon Ribbens wrote:
> On 2017-08-24, Chris Angelico wrote:
>> 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?
On 2017-08-24, Chris Angelico wrote:
> On Fri, Aug 25, 2017 at 12:17 AM, Jon Ribbens
> wrote:
>> On 2017-08-24, Chris Angelico wrote:
>>> On Thu, Aug 24, 2017 at 9:43 PM, Jon Ribbens
>>> wrote:
Where did you explain how it can be done without help? As far as I'm
aware, you can't clo
On Thursday, August 24, 2017 at 5:02:12 PM UTC+1, Chris Angelico wrote:
>
> (Caveat: I have no idea how this works on Windows. I do expect,
> though, that it will abort the connection without terminating the
> process, just like it does on Unix.)
>
> ChrisA
There was a big thread "cross platform
On Fri, Aug 25, 2017 at 5:07 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Fri, Aug 25, 2017 at 3:40 AM, Marko Rauhamaa wrote:
>>> Signals are an arcane Unix communication method. I strongly recommend
>>> against using signals for anything but terminating a process, and even
>>> then you h
Chris Angelico :
> On Fri, Aug 25, 2017 at 3:40 AM, Marko Rauhamaa wrote:
>> Signals are an arcane Unix communication method. I strongly recommend
>> against using signals for anything but terminating a process, and even
>> then you have to be extra careful.
>>
>> I have seen code that uses signa
On Fri, Aug 25, 2017 at 3:40 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Fri, Aug 25, 2017 at 12:17 AM, Jon Ribbens
>> wrote:
>>> 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
Chris Angelico :
> On Fri, Aug 25, 2017 at 12:17 AM, Jon Ribbens
> wrote:
>> 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 s
On Fri, Aug 25, 2017 at 12:17 AM, Jon Ribbens wrote:
> On 2017-08-24, Chris Angelico wrote:
>> On Thu, Aug 24, 2017 at 9:43 PM, Jon Ribbens
>> 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
>
On 2017-08-24, Chris Angelico wrote:
> On Thu, Aug 24, 2017 at 9:43 PM, Jon Ribbens
> 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
On Thu, Aug 24, 2017 at 9:43 PM, Jon Ribbens wrote:
> On 2017-08-23, Chris Angelico wrote:
>> On Thu, Aug 24, 2017 at 8:54 AM, Jon Ribbens
>> wrote:
>>> On 2017-08-23, Chris Angelico wrote:
Yes and no. If requests provided a 'cancel query' feature, it would
play nicely with everythin
On 2017-08-23, Chris Angelico wrote:
> On Thu, Aug 24, 2017 at 8:54 AM, Jon Ribbens
> wrote:
>> On 2017-08-23, Chris Angelico wrote:
>>> Yes and no. If requests provided a 'cancel query' feature, it would
>>> play nicely with everything else, but (a) the entire concept here is
>>> that the requ
On Thu, Aug 24, 2017 at 8:54 AM, Jon Ribbens wrote:
> On 2017-08-23, Chris Angelico wrote:
>> Yes and no. If requests provided a 'cancel query' feature, it would
>> play nicely with everything else, but (a) the entire concept here is
>> that the request has stalled, so you COULD just ignore the p
On 2017-08-23, Chris Angelico wrote:
> Yes and no. If requests provided a 'cancel query' feature, it would
> play nicely with everything else, but (a) the entire concept here is
> that the request has stalled, so you COULD just ignore the pending
> query and pretend it's failed without actually ca
Chris Angelico :
> What I said was that you don't need threading or alarms because most
> of the time you can let the user use SIGINT. And without the (utterly
> totally useless) threading that you have here, it works flawlessly:
> Ctrl-C instantly breaks the recv call.
Oh, if you give up threadi
On Thu, Aug 24, 2017 at 2:59 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> But also, this honestly isn't as big an issue as you might think. If
>> the user thinks a program has been running for too long, s/he can hit
>> Ctrl-C. Voila! Signal is sent, which aborts a socket read,
>
> Well, no, i
Chris Angelico :
> But also, this honestly isn't as big an issue as you might think. If
> the user thinks a program has been running for too long, s/he can hit
> Ctrl-C. Voila! Signal is sent, which aborts a socket read,
Well, no, it doesn't. First run:
==
On Thu, Aug 24, 2017 at 12:52 AM, Jon Ribbens wrote:
> OK cool, so circling back to where you were - which is the same place
> that the 'requests' developers are - which is the claim that requests
> does not need to provide an "overall timeout" feature because you
> can cancel the request yourself
On 2017-08-23, Chris Angelico wrote:
> On Wed, Aug 23, 2017 at 10:52 PM, Jon Ribbens
> wrote:
>> Yes, what I was interested to learn was how the monitoring thread can
>> "cut off" the requesting thread.
>
> Ah, I see. That partly depends on your definition of "cut off", and
> how it needs to int
Jon Ribbens :
> Yes, what I was interested to learn was how the monitoring thread can
> "cut off" the requesting thread.
In general, that cannot be done. Often, you resort to a dirty trick
whereby the monitoring thread closes the I/O object requesting thread is
waiting on, triggering an immediate
On Wed, Aug 23, 2017 at 10:52 PM, Jon Ribbens wrote:
> On 2017-08-23, Chris Angelico wrote:
>> On Wed, Aug 23, 2017 at 9:10 PM, Jon Ribbens
>> wrote:
>>> I am interested to learn what you mean by "with a thread". How would
>>> one execute a requests, er, request in a thread with a proper timeou
On 2017-08-23, Chris Angelico wrote:
> On Wed, Aug 23, 2017 at 9:10 PM, Jon Ribbens
> wrote:
>> I am interested to learn what you mean by "with a thread". How would
>> one execute a requests, er, request in a thread with a proper timeout?
>
> Assuming that by "proper timeout" you mean "limit the
On Wed, Aug 23, 2017 at 9:10 PM, Jon Ribbens wrote:
> On 2017-08-22, Chris Angelico wrote:
>> On Wed, Aug 23, 2017 at 5:06 AM, Jon Ribbens
>> wrote:
>>> I have no idea what you mean here. The only sane way to implement the
>>> request timeout is to provide both types of timeout.
>>
>> You could
On 2017-08-22, Chris Angelico wrote:
> On Wed, Aug 23, 2017 at 5:06 AM, Jon Ribbens
> wrote:
>> I have no idea what you mean here. The only sane way to implement the
>> request timeout is to provide both types of timeout.
>
> You could provide both, but since one of them can be handled
> externa
Skip Montanaro writes:
> ...
> Given the semantics of timeouts which percolate up from the socket
> level, I agree with Chris. It has a particular meaning, that
> implemented by the underlying socket layer. Unfortunately, the word
> "timeout" can take on related (but different) meanings, depending
> You could provide both, but since one of them can be handled
> externally (with a thread, with a SIGALRM, or with some other sort of
> time limiting), the other one MUST be provided by the request.
Given the semantics of timeouts which percolate up from the socket
level, I agree with Chris. It h
On Wed, Aug 23, 2017 at 5:06 AM, Jon Ribbens wrote:
>> You can always add in the overall timeout separately. If the low-level
>> timeout were implemented that way, there would be no way to externally
>> add the other form of timeout. Therefore the only sane way to
>> implement the request timeout
On Wed, Aug 23, 2017 at 5:10 AM, MRAB wrote:
> On 2017-08-22 19:43, Chris Angelico wrote:
>>
>> On Wed, Aug 23, 2017 at 4:14 AM, Jon Ribbens
>> wrote:
>>>
>>> On 2017-08-22, Chris Angelico wrote:
On Wed, Aug 23, 2017 at 2:58 AM, Jon Ribbens
wrote:
>
> Yes. There is no tim
On 2017-08-22, Chris Angelico wrote:
> The low-level timeout will distinguish between those. If you want a
> high-level timeout across the entire job, you can do that too, but
> then you have to figure out exactly how long is "too long". Let's say
> you set a thirty-second timeout. Great! Now some
On 2017-08-22 19:43, Chris Angelico wrote:
On Wed, Aug 23, 2017 at 4:14 AM, Jon Ribbens wrote:
On 2017-08-22, Chris Angelico wrote:
On Wed, Aug 23, 2017 at 2:58 AM, Jon Ribbens wrote:
Yes. There is no timeout feature that can be used to limit the total
time a 'requests' request takes. Some
On Wed, Aug 23, 2017 at 4:31 AM, Grant Edwards
wrote:
> On 2017-08-22, Chris Angelico wrote:
>
>> """
>> Once your client has connected to the server and sent the HTTP
>> request, the read timeout is the number of seconds the client will
>> wait for the server to send a response. (Specifically, i
On Wed, Aug 23, 2017 at 4:14 AM, Jon Ribbens wrote:
> On 2017-08-22, Chris Angelico wrote:
>> On Wed, Aug 23, 2017 at 2:58 AM, Jon Ribbens
>> wrote:
>>> Yes. There is no timeout feature that can be used to limit the total
>>> time a 'requests' request takes. Some people might think that this is
On 2017-08-22, Chris Angelico wrote:
> """
> Once your client has connected to the server and sent the HTTP
> request, the read timeout is the number of seconds the client will
> wait for the server to send a response. (Specifically, it's the number
> of seconds that the client will wait between
On 2017-08-22, Chris Angelico wrote:
> On Wed, Aug 23, 2017 at 2:58 AM, Jon Ribbens
> wrote:
>> Yes. There is no timeout feature that can be used to limit the total
>> time a 'requests' request takes. Some people might think that this is
>> a serious flaw in the requests library that would need
On Wed, Aug 23, 2017 at 2:58 AM, Jon Ribbens wrote:
> On 2017-08-22, Skip Montanaro wrote:
>> I'm using the requests module with timeouts to fetch URLs, for example:
>>
>> response = requests.get("http://www.google.com/";, timeout=10)
>>
>> I understand the timeout value in this case applies
> """
> Once your client has connected to the server and sent the HTTP
> request, the read timeout is the number of seconds the client will
> wait for the server to send a response. (Specifically, it's the number
> of seconds that the client will wait between bytes sent from the
> server. In 99.9%
On 2017-08-22, Skip Montanaro wrote:
> I'm using the requests module with timeouts to fetch URLs, for example:
>
> response = requests.get("http://www.google.com/";, timeout=10)
>
> I understand the timeout value in this case applies both to creating the
> connection and fetching the remote co
On Wed, Aug 23, 2017 at 12:02 AM, Skip Montanaro
wrote:
> I'm using the requests module with timeouts to fetch URLs, for example:
>
> response = requests.get("http://www.google.com/";, timeout=10)
>
> I understand the timeout value in this case applies both to creating the
> connection and fet
I'm using the requests module with timeouts to fetch URLs, for example:
response = requests.get("http://www.google.com/";, timeout=10)
I understand the timeout value in this case applies both to creating the
connection and fetching the remote content. Can the server dribble out the
content (s
48 matches
Mail list logo
