classification
Title: multiprocessing.Pipe problem: "handle out of range in select()"
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.4, Python 3.2, Python 3.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Erez.Sh, William.Edwards, asksol, danken, dmalcolm, giampaolo.rodola, haypo, jnoller, neologix, pitrou, python-dev, sbt, synapse
Priority: normal Keywords: patch

Created on 2010-11-25 11:15 by synapse, last changed 2013-02-26 11:34 by sbt. This issue is now closed.

Files
File name Uploaded Description Edit
tester.py synapse, 2010-11-25 11:15 tester application
multiproc.patch synapse, 2010-11-25 11:16 multiprocessing patch
multiproc2.patch Erez.Sh, 2011-06-14 09:12 multiprocessing patch refined
issue10527.patch giampaolo.rodola, 2012-10-22 16:51 review
issue10527-2.patch giampaolo.rodola, 2012-12-28 20:11 review
issue10527-3.patch giampaolo.rodola, 2012-12-30 23:54 review
Messages (49)
msg122349 - (view) Author: Gergely Kálmán (synapse) Date: 2010-11-25 11:15
Hello,

I have a code that uses multiprocessing.Pipe to communicate with subprocesses. Spawning 500 subprocesses this way works like a charm, but when spawning about 600 of them the pipe ends raise the exception: "handle out of range in select()". I realized that this is because of the FD_SETSIZE limit. To address the situation I quickly hacked together a patch that uses poll() instead of select(), which solves the problem for me. I don't know the reason why select() was chosen for this task (maybe because of windows) but wouldn't it be better to use polling where possible?

I've attached the tester. Beware, running it may use up all memory in your system, so be careful!

Gergely Kalman
msg122350 - (view) Author: Gergely Kálmán (synapse) Date: 2010-11-25 11:16
And this is the patch that I wrote.

It applies to python 3.2.

Hope this helps

Gergely Kalman
msg138301 - (view) Author: Dan Kenigsberg (danken) Date: 2011-06-14 08:23
I would rate this issue as a performance bug, not a mere feature request. If the python process has more than 1023 open file descriptors, multiprocessing.Pipe.poll() becomes unusable. This is a serious barrier to using multiprocessing in a complex server.
msg138305 - (view) Author: Erez Sh (Erez.Sh) Date: 2011-06-14 09:12
I support this change. Putting an arbitrary limitation on the amount of supported subprocesses is disastrous for complex software.

Gergely's patch seems good. I would only like to suggest a small cosmetic refinement to it, which removes some dead code.
msg138310 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-06-14 11:14
This code has changed a lot in Python 3.3 (it is now located in Lib/multiprocessing/connection.py). Can you post a patch against the development tip ("default" branch)?

See http://docs.python.org/devguide/setup.html if you need more information.
msg138345 - (view) Author: Dave Malcolm (dmalcolm) (Python committer) Date: 2011-06-14 18:17
The analogous code within Modules/selectmodule.c uses
  #ifdef HAVE_POLL
to guard the poll-using code, to support non-Windows platforms that don't have "poll".

Presumably a patch for this should do the same.
msg138346 - (view) Author: Dave Malcolm (dmalcolm) (Python committer) Date: 2011-06-14 18:20
Also, I see that Modules/selectmodule.c has some painful-looking workarounds involving "HAVE_BROKEN_POLL", which presumably would also be applicable here.
msg138391 - (view) Author: Dave Malcolm (dmalcolm) (Python committer) Date: 2011-06-15 21:26
[for reference: issue 11743 covered Antoine's rewrite of the connection class to be pure python, for 3.3 (re msg138310)]
msg173239 - (view) Author: William Edwards (William.Edwards) Date: 2012-10-18 08:28
issue 16259 has just been closed as a dup of this one.  Does this mean that this one will be fixed in Python 2.x too?
msg173240 - (view) Author: William Edwards (William.Edwards) Date: 2012-10-18 08:29
Apologies, I meant:

issue 16269 has just been closed as a dup of this one.  Does this mean that this one will be fixed in Python 2.x too?
msg173241 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2012-10-18 08:34
Not necessarily. It just means the other one was a duplicate.
msg173242 - (view) Author: William Edwards (William.Edwards) Date: 2012-10-18 08:35
That was my fear; I raise an issue hurting my 2.x servers in
production, and its closed as duplicate instead of not-going-to-fix?
msg173264 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2012-10-18 12:49
If an issue is a duplicate of another one it gets closed as a duplicate, and that's it basically.
This issue is still open and this is where the matter should be discussed.
msg173545 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2012-10-22 16:51
A preliminary patch is in attachment.
By default it uses select() but looks for ValueError (raised in case FD_SETSIZE gets hit) and falls back on using poll().

This is the failure I get when running tests on Linux.
It is related to issue 3321 and I'm not sure what to do with it (remove the test maybe?).


======================================================================
FAIL: test_invalid_handles (__main__.TestInvalidHandle)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_multiprocessing.py", line 2852, in test_invalid_handles
    self.assertRaises((ValueError, IOError), conn.poll)
AssertionError: (<class 'ValueError'>, <class 'OSError'>) not raised by poll
msg173548 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-10-22 18:14
I don't like this patch since it makes the implementation poorly testable. Moreover, behaviour might change subtly when the fd becomes > 512. I think that instead the code should always use poll() on platforms where it is available.
msg173549 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-10-22 18:15
By the way, I think this is a bug rather than a performance issue.
msg173553 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2012-10-22 18:31
Using poll() by default is controversial for 2 reasons, I think:

#1 - a certain slowdown is likely to be introduced (I'll measure it)

#2 - current wait() implementation allows to specify a list of file descriptors and/or Connections objects. 
select() can deal with both while poll() does not (it will return a list of integers rather than a list of Connection instances).

I'm not sure how "public" multiprocessing.connection.wait() is considered and how much backward compatibility should matter in this case.


> behaviour might change subtly when the fd becomes > 512

What do you mean?
msg173554 - (view) Author: Richard Oudkerk (sbt) * (Python committer) Date: 2012-10-22 18:34
> A preliminary patch is in attachment.
> By default it uses select() but looks for ValueError (raised in case 
> FD_SETSIZE gets hit) and falls back on using poll().
>
> This is the failure I get when running tests on Linux.
> It is related to issue 3321 and I'm not sure what to do with it (remove > the test maybe?).

I guess the patch could do

    if any(x[1] & POLLNVAL for x in ret):
        raise ValueError('invalid file descriptor')

Also, I don't think there is any need to unregister the fds since you are just removing entries from an internal dict which will be garbage collected.

I don't know if patching 2.7, 3.2, 3.3 to use/fallback on poll() would be allowed as a bug fix.  When, if ever, will the next 2.7 release happen?
msg173555 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-10-22 18:41
> Using poll() by default is controversial for 2 reasons, I think:
> 
> #1 - a certain slowdown is likely to be introduced (I'll measure it)

That sounds like premature optimization. If you are concerned about that
you could add some caching of the poll object.

> #2 - current wait() implementation allows to specify a list of file
> descriptors and/or Connections objects. 
> select() can deal with both while poll() does not (it will return a
> list of integers rather than a list of Connection instances).

Well, can't you just create a mapping of the fds to the objects?

Your patch already has that problem by the way, and it's even worse
since it will trigger in random conditions (when some fd is > 512).
msg173556 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2012-10-22 18:43
Still not getting what you refer to when you talk about > 512 fds problem.
msg173558 - (view) Author: Richard Oudkerk (sbt) * (Python committer) Date: 2012-10-22 18:47
> Using poll() by default is controversial for 2 reasons, I think:
>
> #1 - a certain slowdown is likely to be introduced (I'll measure it)

With a single fd poll is a bit faster than select:

$ python -m timeit -s 'from select import select' 'select([0],[],[],0)'
100000 loops, best of 3: 2.99 usec per loop

$ python -m timeit -s 'from select import poll, POLLIN' 'p=poll();p.register(0,POLLIN);p.poll(0)'
100000 loops, best of 3: 2.8 usec per loop

The single fd case is the most important one -- see below.

> #2 - current wait() implementation allows to specify a list of file
> descriptors and/or Connections objects. 
> select() can deal with both while poll() does not (it will return a 
> list of integers rather than a list of Connection instances).
>
> I'm not sure how "public" multiprocessing.connection.wait() is 
> considered and how much backward compatibility should matter in this > case.

It was introduced in Python 3.3 and is only really there to allow cross platform Windows/Unix multiplexing.  It is (now) also used internally by Connection.poll() and Queue.get() with a single fd.

In retrospect it would probably have been better to have implemented poll style multiplexing on Windows.
msg173559 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-10-22 18:50
> Still not getting what you refer to when you talk about > 512 fds problem.

By 512 I mean FD_SETSIZE :)
msg173560 - (view) Author: Richard Oudkerk (sbt) * (Python committer) Date: 2012-10-22 18:55
> Still not getting what you refer to when you talk about > 512 fds
> problem.

Whether you get back the original objects or only their fds will depend on whether some fd was larger than FD_SETSIZE.
msg173563 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2012-10-22 20:27
See also http://bugs.python.org/issue14635.
This problem affects any single use of select(): instead of using an ad-hoc wrapper in each module, it would probably make sense to add a higher level selector class to the select module which would fallback on the right syscall (i.e. poll() if available, or /dev/poll on Solaris-like).
msg173564 - (view) Author: Richard Oudkerk (sbt) * (Python committer) Date: 2012-10-22 21:02
> This problem affects any single use of select(): instead of using an 
> ad-hoc wrapper in each module, it would probably make sense to add a 
> higher level selector class to the select module which would fallback on 
> the right syscall (i.e. poll() if available, or /dev/poll on Solaris-
> like).

Doesn't Solaris have poll()?  If so then I don't see why one would want to use /dev/poll in the single fd case.
msg173582 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2012-10-23 07:38
>> This problem affects any single use of select(): instead of using an
>> ad-hoc wrapper in each module, it would probably make sense to add a
>> higher level selector class to the select module which would fallback on
>> the right syscall (i.e. poll() if available, or /dev/poll on Solaris-
>> like).
>
> Doesn't Solaris have poll()?  If so then I don't see why one would want to use /dev/poll in the single fd case.

Because it offers better performance than poll(): you don't have to
keep passing the FD at each syscall (note that I'm not talking about
the signal FD case, but about a generic polling API).

Also note that microbenchmarks with one FD isn't really meaningful,
since in real life the FD won't be ready at least part of the time:
like Antoine, I think that worrying about performance impact is really
a premature optimization (unless real benchmarks prove otherwise).
msg178422 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2012-12-28 20:11
New patch in attachment.
It always uses poll() and maintains and internal fd/Connection map.
I get one failure due to the returned list being sorted differently than when using select() though.


======================================================================
FAIL: test_wait_integer (__main__.TestWait)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_multiprocessing.py", line 3277, in test_wait_integer
    self.assertEqual(res, [p.sentinel, b])
AssertionError: Lists differ: [<multiprocessing.connection.C... != [7, <multiprocessing.connectio...

First differing element 0:
<multiprocessing.connection.Connection object at 0x7f8924fccd30>
7

- [<multiprocessing.connection.Connection object at 0x7f8924fccd30>, 7]
?                                                                  ---

+ [7, <multiprocessing.connection.Connection object at 0x7f8924fccd30>]
?  +++




I don't how important this is.
If it's not tests can be adapted accordingly.
msg178432 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-12-28 21:25
The order of the results is probably unimportant.
msg178626 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2012-12-30 23:54
Updated patch including test fixes is in attachment.
msg178656 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2012-12-31 09:36
The patch looks good, however there's something really bothering me:
in issue #14635, the same type of patch was applied to telnetlib,
here, it's multiprocessing and AFAICT, any single use of select() in
the standard library is subject to this FD_SETSIZE limitation.
That why I think it could probably be a good idea to expose a
high-level "selector" object in the select module, which would use the
"right" syscall transparently (e.g. select, poll or /dev/poll), with a
unified API. This would make writing portable and efficient I/O
multiplexing code much easier, not only in the stdlib, but also for
end-users.
msg178677 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2012-12-31 14:13
I know. I proposed something like that here: http://mail.python.org/pipermail/python-ideas/2012-May/015223.html.
In theory all the necessary pieces are already there. What's missing is an agreement on what the API should look like, and that's the hard part 'cause it should be the most generic as possible.
msg178678 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-12-31 14:26
> I know. I proposed something like that here:
> http://mail.python.org/pipermail/python-ideas/2012-May/015223.html.
> In theory all the necessary pieces are already there. What's missing
> is an agreement on what the API should look like, and that's the hard
> part 'cause it should be the most generic as possible.

Well, there was a lot of bikeshedding and pie-in-the-sky arguments in
that thread, but I think the original idea of a small wrapper is good
enough. Let Guido do the grand async shakeup separately.

Also, I've changed my mind: I think select would be an ok module for
this :)
msg178692 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2012-12-31 15:29
Well, for now I'd say let's just check in this patch as-is.
I would be keen on considering this a bug and hence address the patch for Python 2.7, 3.2, 3.3 and 3.4.
msg178703 - (view) Author: Roundup Robot (python-dev) Date: 2012-12-31 16:40
New changeset 5530251d9cac by Giampaolo Rodola' in branch '3.2':
Fix issue 10527: make multiprocessing use poll() instead of select() if available.
http://hg.python.org/cpython/rev/5530251d9cac

New changeset d89891f3f769 by Giampaolo Rodola' in branch '3.3':
Fix issue 10527: make multiprocessing use poll() instead of select() if available.
http://hg.python.org/cpython/rev/d89891f3f769

New changeset e971a70984b8 by Giampaolo Rodola' in branch 'default':
Fix issue 10527: make multiprocessing use poll() instead of select() if available.
http://hg.python.org/cpython/rev/e971a70984b8
msg178704 - (view) Author: Roundup Robot (python-dev) Date: 2012-12-31 16:44
New changeset c5c27b84d7af by Giampaolo Rodola' in branch '2.7':
Fix issue 10527: make multiprocessing use poll() instead of select() if available.
http://hg.python.org/cpython/rev/c5c27b84d7af
msg178890 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2013-01-03 01:51
> New changeset c5c27b84d7af by Giampaolo Rodola' in branch '2.7':
> Fix issue 10527: make multiprocessing use poll() instead of select() if available.
> http://hg.python.org/cpython/rev/c5c27b84d7af

This changeset broke many buildbots, at least:
http://buildbot.python.org/all/builders/x86%20XP-5%202.7/builds/439/steps/test/logs/stdio

  File "D:\Buildslave\2.7.moore-windows\build\lib\multiprocessing\connection.py", line 203, in <module>
    if hasattr(select, 'poll'):
NameError: name 'select' is not defined

(I reopen the issue)
msg178893 - (view) Author: Roundup Robot (python-dev) Date: 2013-01-03 01:55
New changeset 7cf4ea64f603 by Giampaolo Rodola' in branch '2.7':
issue 10527: fix missing import
http://hg.python.org/cpython/rev/7cf4ea64f603

New changeset d565d862545c by Giampaolo Rodola' in branch '3.2':
issue 10527: fix missing import
http://hg.python.org/cpython/rev/d565d862545c
msg178894 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2013-01-03 01:57
My bad, sorry. It should be fixed now.
msg179895 - (view) Author: Richard Oudkerk (sbt) * (Python committer) Date: 2013-01-13 21:06
The commits did not have the intended effect.

They just define a _poll() function (and only on Windows) and it is not referenced anywhere else.

I will look in to fixing this -- on 2.7 and 3.2 this will need to be done in the C code.
msg179902 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2013-01-13 23:30
What do you mean? The intent was to use poll() instead of select() anywhere available in order to avoid running out of fds.
The change didn't affect Windows because as of right now select() is the only thing available.
msg179907 - (view) Author: Richard Oudkerk (sbt) * (Python committer) Date: 2013-01-14 00:24
> What do you mean? The intent was to use poll() instead of select() 
> anywhere available in order to avoid running out of fds.
> The change didn't affect Windows because as of right now select() is 
> the only thing available.

The change *only* effects Windows.  Currently the code goes

    if sys.platform != 'win32':
        ...
    else:
        if hasattr(select, 'poll'):
            def _poll(fds, timeout):
                ...
        else:
            def _poll(fds, timeout):
                ...

So _poll() is only defined when sys.platform == 'win32'.

Furthermore, the _poll() function is never used anywhere: ConnectionBase.poll() uses Connection._poll(), which uses wait(), which uses select().
msg179908 - (view) Author: Richard Oudkerk (sbt) * (Python committer) Date: 2013-01-14 00:32
It looks like the change to multiprocessing/connection.py committed does not match the one uploaded as issue10527-3.patch

changeset 81174:e971a70984b8
     1.1 --- a/Lib/multiprocessing/connection.py
     1.2 +++ b/Lib/multiprocessing/connection.py
     1.3 @@ -509,6 +509,27 @@ if sys.platform != 'win32':
     1.4          return c1, c2
     1.5  
     1.6  else:
     1.7 +    if hasattr(select, 'poll'):
     1.8 +        def _poll(fds, timeout):
     1.9 +            if timeout is not None:
    1.10 +                timeout = int(timeout) * 1000  # timeout is in milliseconds
    1.11 +            fd_map = {}
    1.12 +            pollster = select.poll()
    1.13 +            for fd in fds:
    1.14 +                pollster.register(fd, select.POLLIN)
    1.15 +                if hasattr(fd, 'fileno'):
    1.16 +                    fd_map[fd.fileno()] = fd
    1.17 +                else:
    1.18 +                    fd_map[fd] = fd
    1.19 +            ls = []
    1.20 +            for fd, event in pollster.poll(timeout):
    1.21 +                if event & select.POLLNVAL:
    1.22 +                    raise ValueError('invalid file descriptor %i' % fd)
    1.23 +                ls.append(fd_map[fd])
    1.24 +            return ls
    1.25 +    else:
    1.26 +        def _poll(fds, timeout):
    1.27 +            return select.select(fds, [], [], timeout)[0]
    1.28  
    1.29      def Pipe(duplex=True):
    1.30          '''

issue10527-3.patch:
diff --git a/Lib/multiprocessing/connection.py b/Lib/multiprocessing/connection.py
--- a/Lib/multiprocessing/connection.py
+++ b/Lib/multiprocessing/connection.py
@@ -861,6 +861,27 @@
         return [o for o in object_list if o in ready_objects]
 
 else:
+    if hasattr(select, 'poll'):
+        def _poll(fds, timeout):
+            if timeout is not None:
+                timeout = int(timeout) * 1000  # timeout is in milliseconds
+            fd_map = {}
+            pollster = select.poll()
+            for fd in fds:
+                pollster.register(fd, select.POLLIN)
+                if hasattr(fd, 'fileno'):
+                    fd_map[fd.fileno()] = fd
+                else:
+                    fd_map[fd] = fd
+            ls = []
+            for fd, event in pollster.poll(timeout):
+                if event & select.POLLNVAL:
+                    raise ValueError('invalid file descriptor %i' % fd)
+                ls.append(fd_map[fd])
+            return ls
+    else:
+        def _poll(fds, timeout):
+            return select.select(fds, [], [], timeout)[0]
 
     def wait(object_list, timeout=None):
         '''
@@ -870,12 +891,12 @@
         '''
         if timeout is not None:
             if timeout <= 0:
-                return select.select(object_list, [], [], 0)[0]
+                return _poll(object_list, 0)
             else:
                 deadline = time.time() + timeout
         while True:
             try:
-                return select.select(object_list, [], [], timeout)[0]
+                return _poll(object_list, timeout)
             except OSError as e:
                 if e.errno != errno.EINTR:
                     raise
msg179911 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2013-01-14 00:49
Damn, you're right. I must have messed up something while porting the patch from 3.2 all the way up to 3.4 as the merge produced some conflicts.
msg179914 - (view) Author: Roundup Robot (python-dev) Date: 2013-01-14 01:24
New changeset 831f49cc00fc by Giampaolo Rodola' in branch 'default':
fix for previous commit related to issue 10527 which didn't have the intended effect as per http://bugs.python.org/issue10527#msg179895
http://hg.python.org/cpython/rev/831f49cc00fc
msg179916 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2013-01-14 01:28
3.3 and 3.4 branches should now be fixed.
2.7 and 3.2 still need to be fixed and the code from connections.py removed.
Sorry for the mess up.
msg179994 - (view) Author: Roundup Robot (python-dev) Date: 2013-01-15 00:50
New changeset da5e520a7ba5 by Richard Oudkerk in branch '2.7':
Issue #10527: Use poll() instead of select() for multiprocessing pipes
http://hg.python.org/cpython/rev/da5e520a7ba5
msg179995 - (view) Author: Roundup Robot (python-dev) Date: 2013-01-15 01:08
New changeset abf111b9a464 by Richard Oudkerk in branch '3.2':
Issue #10527: Use poll() instead of select() for multiprocessing pipes
http://hg.python.org/cpython/rev/abf111b9a464
msg180015 - (view) Author: Roundup Robot (python-dev) Date: 2013-01-15 13:14
New changeset f07435fa6736 by Richard Oudkerk in branch '2.7':
Issue #10527: Remove dead code
http://hg.python.org/cpython/rev/f07435fa6736
msg180016 - (view) Author: Roundup Robot (python-dev) Date: 2013-01-15 13:24
New changeset 49d45151b9ed by Richard Oudkerk in branch '3.2':
Issue #10527: Remove dead code
http://hg.python.org/cpython/rev/49d45151b9ed
History
Date User Action Args
2013-02-26 11:34:05sbtsetstatus: open -> closed
resolution: fixed
stage: commit review -> resolved
2013-01-15 13:24:39python-devsetmessages: + msg180016
2013-01-15 13:14:42python-devsetmessages: + msg180015
2013-01-15 01:08:30python-devsetmessages: + msg179995
2013-01-15 00:50:12python-devsetmessages: + msg179994
2013-01-14 01:28:55giampaolo.rodolasetassignee: giampaolo.rodola ->
messages: + msg179916
2013-01-14 01:24:27python-devsetmessages: + msg179914
2013-01-14 00:49:21giampaolo.rodolasetmessages: + msg179911
2013-01-14 00:32:43sbtsetmessages: + msg179908
2013-01-14 00:24:06sbtsetmessages: + msg179907
2013-01-13 23:30:07giampaolo.rodolasetmessages: + msg179902
2013-01-13 21:06:22sbtsetstatus: closed -> open
resolution: fixed -> (no value)
messages: + msg179895
2013-01-03 01:57:10giampaolo.rodolasetstatus: open -> closed
resolution: fixed
messages: + msg178894
2013-01-03 01:55:37python-devsetmessages: + msg178893
2013-01-03 01:51:13hayposetstatus: closed -> open
resolution: fixed -> (no value)
messages: + msg178890
2012-12-31 16:45:32giampaolo.rodolasetstatus: open -> closed
assignee: giampaolo.rodola
resolution: fixed
stage: patch review -> commit review
2012-12-31 16:44:39python-devsetmessages: + msg178704
2012-12-31 16:40:01python-devsetnosy: + python-dev
messages: + msg178703
2012-12-31 15:29:48giampaolo.rodolasetmessages: + msg178692
2012-12-31 14:26:34pitrousetmessages: + msg178678
2012-12-31 14:13:46giampaolo.rodolasetmessages: + msg178677
2012-12-31 09:36:39neologixsetmessages: + msg178656
2012-12-30 23:54:42giampaolo.rodolasetfiles: + issue10527-3.patch

messages: + msg178626
2012-12-28 21:25:55pitrousetmessages: + msg178432
2012-12-28 20:11:22giampaolo.rodolasetfiles: + issue10527-2.patch

messages: + msg178422
2012-10-23 07:38:30neologixsetmessages: + msg173582
2012-10-22 21:02:16sbtsetmessages: + msg173564
2012-10-22 20:27:21neologixsetnosy: + neologix
messages: + msg173563
2012-10-22 18:55:09sbtsetmessages: + msg173560
2012-10-22 18:50:28pitrousetmessages: + msg173559
2012-10-22 18:47:42sbtsetmessages: + msg173558
2012-10-22 18:43:20giampaolo.rodolasetmessages: + msg173556
2012-10-22 18:41:40pitrousetmessages: + msg173555
2012-10-22 18:34:55sbtsetmessages: + msg173554
2012-10-22 18:31:25giampaolo.rodolasetmessages: + msg173553
2012-10-22 18:15:23pitrousettype: performance -> behavior
messages: + msg173549
versions: + Python 3.2, Python 3.4
2012-10-22 18:14:54pitrousetmessages: + msg173548
2012-10-22 16:51:27giampaolo.rodolasetfiles: + issue10527.patch

messages: + msg173545
2012-10-18 12:49:55giampaolo.rodolasetnosy: + sbt
messages: + msg173264
2012-10-18 08:35:43William.Edwardssetmessages: + msg173242
2012-10-18 08:34:18giampaolo.rodolasetmessages: + msg173241
2012-10-18 08:29:00William.Edwardssetmessages: + msg173240
2012-10-18 08:28:07William.Edwardssetnosy: + William.Edwards
messages: + msg173239
2012-10-18 00:15:40giampaolo.rodolasetnosy: + giampaolo.rodola
2011-06-15 21:26:46dmalcolmsetmessages: + msg138391
2011-06-14 18:20:33dmalcolmsetmessages: + msg138346
2011-06-14 18:17:32dmalcolmsetmessages: + msg138345
2011-06-14 18:14:37dmalcolmsetnosy: + dmalcolm
2011-06-14 11:14:11pitrousetmessages: + msg138310
versions: + Python 3.3, - Python 3.2
2011-06-14 09:57:51hayposetnosy: + pitrou, haypo
2011-06-14 09:12:27Erez.Shsetfiles: + multiproc2.patch
nosy: + Erez.Sh
messages: + msg138305

2011-06-14 08:23:46dankensetnosy: + danken
type: enhancement -> performance
messages: + msg138301
2010-11-25 20:46:23jnollersetnosy: + asksol
2010-11-25 20:12:56ned.deilysetnosy: + jnoller

stage: patch review
2010-11-25 11:16:11synapsesetfiles: + multiproc.patch
keywords: + patch
messages: + msg122350
2010-11-25 11:15:11synapsecreate