On 12 Apr, 11:19 pm, j...@jcea.es wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/13/2010 12:47 AM, Antoine Pitrou wrote:
Jesus Cea jcea.es> writes:
PS: "socket.setdefaulttimeout()" is not enough, because it could
shutdown a perfectly functional connection, just because it was idl
On Mon, Apr 12, 2010 at 4:19 PM, Jesus Cea wrote:
> On 04/13/2010 12:47 AM, Antoine Pitrou wrote:
>> Jesus Cea jcea.es> writes:
>>>
>>> PS: "socket.setdefaulttimeout()" is not enough, because it could
>>> shutdown a perfectly functional connection, just because it was idle for
>>> too long.
>>
>>
On Mon, Apr 12, 2010 at 3:59 PM, Daniel Stutzbach
wrote:
> On Mon, Apr 12, 2010 at 5:34 PM, Jesus Cea wrote:
>>
>> The problem is: linux doesn't uses KEEPALIVE by default.
>
> If you believe the problem is with the Linux kernel, perhaps you should take
> up your case on a more appropriate mailing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/13/2010 12:47 AM, Antoine Pitrou wrote:
> Jesus Cea jcea.es> writes:
>>
>> PS: "socket.setdefaulttimeout()" is not enough, because it could
>> shutdown a perfectly functional connection, just because it was idle for
>> too long.
>
> The socket
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/13/2010 12:59 AM, Daniel Stutzbach wrote:
> Most non-trivial applications use select() or poll() to avoid blocking
> calls and do their own timeout-checking at the application layer, so
> they don't need KEEPALIVE.
I am thinking about python std
On Mon, Apr 12, 2010 at 5:34 PM, Jesus Cea wrote:
> The problem is: linux doesn't uses KEEPALIVE by default.
>
If you believe the problem is with the Linux kernel, perhaps you should take
up your case on a more appropriate mailing list?
Python's socket module is a fairly low-level module, as it
Jesus Cea jcea.es> writes:
>
> PS: "socket.setdefaulttimeout()" is not enough, because it could
> shutdown a perfectly functional connection, just because it was idle for
> too long.
The socket timeout doesn't shutdown anything. It just puts a limit on how much
time recv() and send() can block.
There is no need for the "forced" switch to be guaranteed. The motivation
for the wait is to increase throughput and decrease latency when OS
schedules next thread to run on same core as yielding thread but yielding
thread is about to continue running into CPU intensive library code. An
occasional
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/13/2010 12:09 AM, Guido van Rossum wrote:
> Also I recall reading that keepalives are a very
> controversial concept (since they may actually break connections
> unnecessarily if the internet merely has a hiccup).
That is true, but parameters ar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/13/2010 12:09 AM, Guido van Rossum wrote:
> Are you sure about this? ISTM that in most cases when a server goes
> away unexpectedly the local host will discover this when it next tries
> to use the socket. Also I recall reading that keepalives ar
Are you sure about this? ISTM that in most cases when a server goes
away unexpectedly the local host will discover this when it next tries
to use the socket. Also I recall reading that keepalives are a very
controversial concept (since they may actually break connections
unnecessarily if the intern
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Debugging a strange problem today, I got the following result:
Sockets open by stdlib libraries are open without the "keepalive"
option, so the system default is used. The system default under linux is
"no keepalive".
So, if you are using a URLlib co
On 08/04/2010, Victor Stinner wrote:
> Le jeudi 08 avril 2010 08:11:09, Yaniv Aknin a écrit :
>> Issue #7978 (http://bugs.python.org/issue7978) describes a bug in
>> SocketServer where a received signal in SocketServer's select() call
>> will raise an uncaught exception due to EINTR. The proposed
That code will not switch to another thread if the condition variable either
does not actually block the thread on the call (which is allowed by the
standard to give implementations some flexibility for making it work
correctly read the standard reasoning for more information), or the thread
is w
Please describe clearly a step by step scenario in which that code will
fail.
On Mon, Apr 12, 2010 at 10:25 PM, Peter Portante wrote:
> Yes, but unless you loop until the predicate is False, no forced switch
> is guaranteed to occur. You might as well remove the code. If you want to
> keep the
Yes, but unless you loop until the predicate is False, no forced switch is
guaranteed to occur. You might as well remove the code. If you want to keep
the code as is, call me when you need a life guard to help debug mystifying
behaviors. ;) -peter
On 4/12/10 3:17 PM, "Nir Aides" wrote:
> The lo
At some point there was a loop, later it remained since I feel it is more
readable than a bunch of nested if-else clauses.
Should probably replace with do {...} while(0)
I was conditioned with electrical shocks in the dungeons of a corporate to
always use for loops.
I uploaded the patch to Rietve
The loop-less wait is similar to the one in new GIL. It is used to force a
switch to next thread in particular scenario and the motivation is explained
in comment to another if clause a few lines up. Those two if clauses can be
joined though.
On Mon, Apr 12, 2010 at 3:37 PM, Peter Portante
wrote:
On 4/11/2010 6:43 AM, Greg Ewing wrote:
import sys
try:
raise ValueError
except ValueError:
tb = sys.exc_info()[2]
print tb
print tb.__class__
# 3.1.2
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
On Mon, 12 Apr 2010 19:06:29 +0530, Anand Balachandran Pillai
wrote:
>I am surprised to see that the bug-tracker
> doesn't have an OS classifier or ability to add
> tags ? Since a number of issues reported seem to
> be OS specific (one can find a lot of Windows only
> issues upon a se
On Mon, Apr 12, 2010 at 07:06:29PM +0530, Anand Balachandran Pillai wrote:
> I am surprised to see that the bug-tracker
> doesn't have an OS classifier or ability to add
> tags ? Since a number of issues reported seem to
There is one. In the Components you can do a multiple select and i
Hi,
I am surprised to see that the bug-tracker
doesn't have an OS classifier or ability to add
tags ? Since a number of issues reported seem to
be OS specific (one can find a lot of Windows only
issues upon a search), won't adding these fields
help bug triaging ?
I am not sure which so
On Sun, Apr 11, 2010 at 1:13 AM, average wrote:
>
> There are so many features taken from 3.0 that I fear that it will
> postpone its adoption interminably (it is, in practice, treated as
> "beta" software itself). By making it doctrine that it won't be
> official until the next "major" Python re
And why the for(;;) loop in bfs_schedule()? I don¹t see a code path that
would loop there. Perhaps I am missing it ...
-peter
On 4/12/10 8:37 AM, "Peter Portante" wrote:
> Hmm, so I see in bfs_yield():
>
> +if (tstate != NULL && bfs_thread_switch == tstate) {
> +COND_RESET(tstate-
Hmm, so I see in bfs_yield():
+if (tstate != NULL && bfs_thread_switch == tstate) {
+COND_RESET(tstate->bfs_cond);
+COND_WAIT(tstate->bfs_cond, bfs_mutex);
+}
So, to me, the above code says, ³Wait for the condition that tstate is
either NULL, or bfs_thread_switch does not
Hi Peter,
There is no need for a loop in bfs_yield().
On Mon, Apr 12, 2010 at 4:26 AM, Peter Portante
wrote:
> Nir,
>
> Per the POSIX standard, both pthread_cond_wait() and
> pthread_cond_timedwait() need to be performed in a loop. See the fourth
> paragraph of the description from:
>
>
> htt
Thank you all. My decision at the moment is a compiler for PICs to
accept a language more like python as possible instead of C.
How is a college project "solo", I can guarantee at least the first
part, a lexical analyzer.
Ass: Wil ('.')
___
Python-Dev ma
27 matches
Mail list logo
