delta/python-packages/eventlet.git/eventlet/greenio.py, branch python3-clean

Fix "maximum recursion depth exceeded in GreenSocket.del"

2014-10-16T22:02:01+00:00

Closes #137
Closes #148

Remove dead code

2014-10-15T23:01:04+00:00

Reformat with autopep8

2014-10-11T00:41:30+00:00

Python 3 compat: Improve various bits

2014-10-10T08:17:41+00:00

This includes changes to WSGI, websocket, bytes/str/unicode handling,
SSL, backdoor, greenio and tests.

Some comments and conditionals (PY2/PY3) were added for clarity

GH issues:

Closes #106
Closes #111
Closes #118
Closes #141

Incidentally should also close #135 (reopen if didn't)

cc #6

greenio: When we mark a socket as closed we still need to be able to close it

2014-08-27T21:51:44+00:00

https://github.com/eventlet/eventlet/issues/122

After a long running job that highlighted a previous known issue with
Second Simultaneous Read issue I used http://mg.pov.lt/objgraph/ to print
out all the types and counts still referenced by the GC.

Before this patch I was seeing GreenSocket and _socketobject types been
referenced. Depending on how long I ran the test job for I saw more references
to these objects. After this patch I see no reference no matter how long I
run my test for.

PEP-8 fixes

2014-08-27T06:21:55+00:00

hubs: defang after remove; related to second simultaneous read issue

2014-08-12T08:10:42+00:00

https://github.com/eventlet/eventlet/issues/94

We have to defang the listener after removing it from the hub

Otherwise we never actaully remove it from the hub and get a return of the
second simultanous read.

This should fix this issue.

Turn off __builtin__ monkey patching by default

The reason is that eventlet.greenio.GreenPipe tries to
adapt an original file f, and performs the following check
isinstance(f, file) f is an original file object with file
is now our file method. This fails causing TypeError

nova-api exercises this

Fix up zmq to use the extended add signature

Having heard no problems relating eventlet and zmq,
I'm not going to dive in and drop random pataches against
it. If the 'Second simultaneous *er' crops up against
zmw then we at least now have the machinery to
address it.

Fix second simultaneous read (parallel paramiko issue)

2014-08-11T21:14:58+00:00

https://github.com/eventlet/eventlet/issues/94

Because of the way paramiko utilises a client thread to manage its
communication, it's not been compatible with eventlet when run in
parallel.

It's not the only place these problems would arise.

This stemmed from the reuse of a fileno by the underlying OS.
Because listeners are registered against this descriptor, it would
be possible for old listeners to receive events destined for newer
descriptors; occasionally code would attempt to utilise the new
descriptor from a different greenlet, giving rise to the 'second
simultaneous read' problem.

Whenever a Python object is created to wrap one of these filenos,
we now signal the hub in order that it can correctly obsolete
extant listeners against that fileno. This is a fairly tricky
operation, due to the way that listeners' threads are interleaved
with the hub's operation - there are a number of small fixes here
to defend against one listener from effectively obsoleting another
when an event is pending against it.

Python 3 compatibility fixes

2014-07-17T22:12:53+00:00

Closes GH-102
Closes GH-103
Closes GH-104

greenio, tpool: python3 compatibility

2014-07-17T22:10:43+00:00

Also:
- PEP-8
- check both EAGAIN/EWOULDBLOCK
- use system implementation of GreenPipe.readinto()