from this patch isn't as good, but still ~15% for the 4
thread case. I hear rumor that platforms other than linux show much
better improvement from the new GIL.
Ross
On Wed, 20 Jan 2010 20:40:38 -0600
Benjamin Peterson wrote:
> 2010/1/20 Ross Cohen :
> > Comments? Suggestions? I&
I put together this patch which switches 2.5.4 over to use the newgil.
This was generated by diffing change 76193 (last in the newgil branch)
against change 76189 and applying that on top of the changes listed in
issue 4293 (http://bugs.python.org/issue4293), specifically 68460, 68461
and 68722. Th
On Fri, Dec 21, 2007 at 11:28:55AM +0100, Christian Heimes wrote:
> Your wrapper is a good implementation. I even found an inconvenience in
> my implementation when I studied your code. My wrapper raised an
> exception when a closed fd was removed with EPOLL_CTL_DEL.
It should be a good reference,
On Thu, Dec 20, 2007 at 06:08:47PM +0100, Christian Heimes wrote:
> I've written wrappers for both mechanisms. Both wrappers are inspired
> from Twisted and select.poll()'s API. The interface is more Pythonic
> than the available wrappers and it reduced the burden on the user. The
> users don't ha
On Sun, Jun 24, 2007 at 10:48:30PM +0200, "Martin v. Löwis" wrote:
> >> I don't see why it is a requirement to *open* the file in
> >> non-inheritable mode. Why is not sufficient to *modify*
> >> an open file to have its handle non-inheritable in
> >> an easy and platform-independent way?
> >
> >
On Sat, May 27, 2006 at 02:27:20AM +0100, Steve Holden wrote:
> Greg Ewing wrote:
> > Rather than adding yet another platform-dependent module,
> > I'd like to see a unified Python interface in the stdlib
> > that uses whichever is the best one available.
> >
> Of course that would mean establishi
On Sat, May 27, 2006 at 08:36:12AM +0200, "Martin v. Löwis" wrote:
> Ross Cohen wrote:
> > epoll also allows 64 bits of data to be tucked away and returned when events
> > happen. Could be useful for saving a dict lookup for every event. However,
> > there are some
I wrote an epoll implementation which can be used as a drop-in replacement
for parts of the select module (assuming the program is using only poll).
The code can currently be used by doing:
import epoll as select
It was released under the Python license on sourceforge:
http://sourceforge.net/proj
On Fri, May 26, 2006 at 11:56:06PM +0200, "Martin v. Löwis" wrote:
> I thought about this (even though I never used it), and I think there
> are good uses for EPOLLET.
There are, if the programmer wants to deal with it. Easy enough to add the
flag and give them the choice. I'll put together a sele
On Fri, May 26, 2006 at 11:43:05PM +0200, Ronald Oussoren wrote:
> >Ok, I'm not familiar with intimate details of kqueue. However, if
> >there
> >were a select.poll implementation based on kqueue, it would still
> >be an
> >improvement, since there isn't *any* implementation on OS X right now.
On Fri, May 26, 2006 at 10:12:15PM +0200, "Martin v. Löwis" wrote:
> That said, I would be in favour of having select.poll "silently" use
> epoll where available. Of course, it would be good if a "cheap" run-time
> test could be made whether epoll is available at run-time (although
> just waiting f
On Fri, May 26, 2006 at 02:49:44PM -0400, Jean-Paul Calderone wrote:
> On Fri, 26 May 2006 14:31:33 -0400, Ross Cohen <[EMAIL PROTECTED]> wrote:
> >
> >I agree that it should go into the select module, but not as a seperate
> >set of calls.
>
> How about "
On Fri, May 26, 2006 at 08:48:42PM +0200, "Martin v. Löwis" wrote:
> Ross Cohen wrote:
> > I agree that it should go into the select module, but not as a seperate
> > set of calls. epoll is strictly better than poll. kqueue is strictly
> > better than poll. Windows h
On Fri, May 26, 2006 at 08:03:12PM +0200, "Martin v. Löwis" wrote:
> Ross Cohen wrote:
> > Is there any interest in incorporating this into the standard python
> > distribution?
>
> I would like to see epoll support in Python, but not in the way PyEpoll
> is pa
On Fri, May 26, 2006 at 01:10:30PM -0400, Jean-Paul Calderone wrote:
> Including a wrapper for this functionality would be quite useful for many
> python network apps. However, I think with ctypes going into 2.5, it might
> be better to consider providing epoll support using a ctypes-based modul
On Fri, May 26, 2006 at 11:47:43AM -0500, [EMAIL PROTECTED] wrote:
>
> Ross> I wrote an epoll implementation which can be used as a drop-in
> Ross> replacement for parts of the select module
> ...
> Ross> Is there any interest in incorporating this into the standard
> Ross> pyt
I wrote an epoll implementation which can be used as a drop-in replacement
for parts of the select module (assuming the program is using only poll).
The code can currently be used by doing:
import epoll as select
It was released under the Python license on sourceforge:
http://sourceforge.net/proj
17 matches
Mail list logo
