[Twisted-Python] pending twisted fixes

[Andrea Arcangeli]

On Thu, May 12, 2005 at 01:02:14AM -0400, Glyph Lefkowitz wrote:
> Andrea Arcangeli wrote:
> 
> >These are the pending fixes for twisted that I'm maintaining on my tree.
> 
> Thanks for reporting these, especially the fix backports.  I guess 

You're very welcome! Thanks for the great twisted work.

> Twisted is a big enough project now that we need to start doing 
> maintenance release trees!

So far my project has been more experimental than twisted, so on the
server side I'm surfing the SVN wave of all projects I depend on ;).
Lack of maintainance release is not a big deal for me as long as SVN
trunk remains usable in semi-production. I keep all installed versions
in a backup directory, so I can downgrade to the previous binaries of
all packages in a few seconds if something breaks.

On the client side hotfixing has been so easy to add that perhaps a more
official list of all potential serious bugs might be enough too. So if
one is affected he can apply the hotfix without even requiring the end
user to upgrade (i.e. avoiding the annoyance from the admin at the
rogers incident).

Infact I was surprised about the rogers decision of rewriting in pure
python. I would understand pure C/C++ to boost performance and increase
the developer base, but pure python isn't going to be better than
python+twisted. I guess they're more used to thread programming than
async driven programming, but thread programming is generally more
complex than async programming. And async programming is quite close to
thread programming, it's simpler because it's like if we were to hold
implicitly a big lock before rescheduling the next context.

On a related note, I wonder how complex it would be to really support
multiple threads listening in epoll and requiring each context to take
its locks, so then different contexts could scale in smp. This would
break all apps, but it could be an optional mode that the app enables
only if it supports multithreading. But anyway I don't need it right
now, this is just a random idea, performance is more than good enough,
if there's a performance problem it's only in the interfaces and
apparently that has been partly addressed by taking zope.interfaces.

> I've seen this problem before but not thought too hard about it. 
> Considering it now, I think the right solution is to add a 
> 'disconnecting' attribute to ITransport, and fix all current Twisted 
> ITransport implementations to include it.  I know that this is about to 
> become an issue for me with Q2Q.

This sounds fine with me ;)

> (Also, should we maybe have a distinction between IStreamTransport and 
> IDatagramTransport, rather than just ITCPTransport/IUDPTransport?  or at 
> least some attributes to introspect, like ".reliable" and ".ordered"?)

Abstracting this bit at the highlevel sounds good too. .stream may also
be a good candidate. .reliable and .ordered are two of the properties
that a stream has, the syscall uses SOCK_STREAM too.

Thanks!