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
47 matches
Mail list logo
