[Python-Dev] Regarding stdlib socket module, _fileobject.flush() method using ._rbufsize instead of ._wbufsize

Hello, Is there a reason why the stdlib socket module _fileobject.flush() method is using ._rbufsize instead of ._wbufsize at line 297 (Python 2.7.3), where it determines the buffer_size value to be used for _sock.sendall()? Does anybody know the history behind this? Based on what I read in the

Re: [Python-Dev] Should the default Python 2.7 web page mention 2.7.5 instead of 2.7.2?

FWIW: The first hit that I saw googling "Python 2.7" brought up that page. On Sat, Aug 17, 2013 at 11:19 AM, Benjamin Peterson wrote: > Fixed, although hopefully there are few links to that page, since it's > really the release page of 2.7.0. > > 2013/8/17 Pe

[Python-Dev] Should the default Python 2.7 web page mention 2.7.5 instead of 2.7.2?

See http://www.python.org/download/releases/2.7/ as of Saturday, August 17th, 2013. "Note: A bugfix release, 2.7.2, is currently available. Its use is recommended." Kinds regards, -peter ___ Python-Dev mai

Re: [Python-Dev] Modules/socketmodule.c: avoiding second fcntl() call worth the effort?

. In eventlet's case, it would appear the code could be taught this fact, and adjusted accordingly. I'll propose a patch for eventlet that will eliminate most of these calls in their case. Thanks for your time, -peter On Sun, Jan 20, 2013 at 1:31 AM, Peter Portante wrote: > I don

Re: [Python-Dev] Modules/socketmodule.c: avoiding second fcntl() call worth the effort?

le() is attempting to dup() the fd, but rfile and wfile end up with objects that share the same fd contained in conn. For eventlet/wsgi.py based webservers, OpenStack Swift is the one I am working with right now, handles millions of requests a day on our customer systems. Seems like these suggeste

[Python-Dev] Modules/socketmodule.c: avoiding second fcntl() call worth the effort?

Hello folks, I noticed while stracing a process that sock.setblocking() calls always result in pairs of fcntl() calls on Linux. Checking 2.6.8, 2.7.3, and 3.3.0 Modules/socketmodule.c, the code seems to use the following (unless I have missed something): delay_flag = fcntl(s->sock_fd, F_GETFL

Re: [Python-Dev] Support for async read/write

Yes, that would be a nice addition. -peter On 10/19/10 12:50 PM, "Jesus Cea" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Current Python lacks support for "aio_*" syscalls to do async IO. I > think this could be a nice addition for python 3.3. > > If you agree, I will create a

Re: [Python-Dev] Thoughts fresh after EuroPython

On 7/25/10 11:42 PM, "Guido van Rossum" wrote: > On Sun, Jul 25, 2010 at 8:31 PM, Peter Portante > wrote: >> FWIW: We use Python at Tabblo, straddled across Python 2.5.4 and 2.6.5. They >> work. And they work well. But we make light use of threads (mostly >> b

Re: [Python-Dev] Thoughts fresh after EuroPython

On 7/25/10 3:19 PM, "Gregory P. Smith" wrote: > > On Sat, Jul 24, 2010 at 7:08 AM, Guido van Rossum wrote: >> >> - Commit privileges: Maybe we've been too careful with only giving >> commit privileges to to experienced and trusted new developers. I >> spoke to Ezio Melotti and from his experie

Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)

Does anybody think that by having problems with the new GIL that it might further weaken the adoption rate for 3k? -peter On 5/19/10 7:00 AM, "David Beazley" wrote: >> From: "Martin v. L?wis" >> To: Dj Gilcrease >> Cc: python-dev@python.org >> Subject: Re: [Python-Dev] Fixing the GIL (with a

Re: [Python-Dev] "Fixing" the new GIL

on systems where it will happen. :) -peter On 4/12/10 3:36 PM, "Nir Aides" wrote: > 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 u

Re: [Python-Dev] "Fixing" the new GIL

te: > 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,

Re: [Python-Dev] "Fixing" the new GIL

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) { &

Re: [Python-Dev] "Fixing" the new GIL

False. -peter On 4/12/10 8:12 AM, "Nir Aides" wrote: > 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(

Re: [Python-Dev] "Fixing" the new GIL

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: > http://www.opengroup.org/onlinepubs/95399/functions/pthread_cond_timedwait > .html For the Windows side, I think you have a

Re: [Python-Dev] "Fixing" the new GIL

Yes, having another thread wait with a timeout is not good. CPU cycles waisted doing things that don¹t help the thread holding the GIL release it. They just note that they are present and then the GIL-holding-thread should be responsible for handling the rest. -peter On 3/16/10 1:11 PM, "Nir Aide

Re: [Python-Dev] "Fixing" the new GIL

On 3/14/10 7:31 AM, "Nir Aides" wrote: > There are two possible problems with Dave's benchmark: > > 1) On my system setting TCP_NODELAY option on the accepted server socket > changes results dramatically. Could you document what you saw and explain how you think TCP_NODELAY makes a difference, i

Re: [Python-Dev] interesting article on regex performance

http://code.google.com/p/re2/ On 3/11/10 8:52 PM, "Neal Becker" wrote: > http://swtch.com/~rsc/regexp/regexp1.html > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http:/