[Twisted-Python] [Fwd: Re: [Zope3-dev] Twisted as server]
I'm going to read this in the morning when I'm more awake. Meanwhile someone else may be interested. Shane is discussing a mixed async/sync mode where threads can write directly to the socket.
On Mon, 2002-02-11 at 18:17, Itamar Shtull-Trauring wrote:
[snip massive email] That was quite a bit of text, if I understand properly -- he was saying that you ought to be able to do proto.transport.write = proto.transport.socket.makefile().write, with some additional buffering trickery for optimization? (It's this sort of communication that makes me want to avoid words like "handler" and "dispatcher" in Twisted wherever possible. I feel bad already for using "Application" and "Scheduler") -- "Cannot stand to be one of many -- I'm not what they are." -Guster, "Rocketship" glyph lefkowitz; ninjaneer, freelance demiurge glyph @ [ninjaneering|twistedmatrix].com
Glyph Lefkowitz wrote:
I think so, yes. Plus some architectural stuff about how they do multiple requests per connection (the task stuff.) Our current transport code would in fact work with threads without any changes (i.e. you could do transport.write in a thread), if not for the fact that the event loop integration (addWriter, addReader) isn't thread safe. Since in threaded mode the Selectable doesn't need to be in the event loop anyway, we just need a flush method for sync mode and a "switch to/from sync mode" method and we could have writing to transports be usable from threads (only one thread at a time, of course.) Another nice thing is the Buffering stuff, which lets you have a buffer that is on disk as well - it would make producers less needed when sending large amounts of data. It would also improve performance of writing large amounts of data on fast connection, since without producers we can write-at-once. See: http://cvs.zope.org/Zope3/lib/python/Zope/Server/?only_with_tag=Zope-3x-bran... DualModeChannel.DualModeChannel is the sync/async switchable transport. Also, I'm starting to feel jealous of Zope3's amount of unittests...
On Mon, 2002-02-11 at 18:17, Itamar Shtull-Trauring wrote:
[snip massive email] That was quite a bit of text, if I understand properly -- he was saying that you ought to be able to do proto.transport.write = proto.transport.socket.makefile().write, with some additional buffering trickery for optimization? (It's this sort of communication that makes me want to avoid words like "handler" and "dispatcher" in Twisted wherever possible. I feel bad already for using "Application" and "Scheduler") -- "Cannot stand to be one of many -- I'm not what they are." -Guster, "Rocketship" glyph lefkowitz; ninjaneer, freelance demiurge glyph @ [ninjaneering|twistedmatrix].com
Glyph Lefkowitz wrote:
I think so, yes. Plus some architectural stuff about how they do multiple requests per connection (the task stuff.) Our current transport code would in fact work with threads without any changes (i.e. you could do transport.write in a thread), if not for the fact that the event loop integration (addWriter, addReader) isn't thread safe. Since in threaded mode the Selectable doesn't need to be in the event loop anyway, we just need a flush method for sync mode and a "switch to/from sync mode" method and we could have writing to transports be usable from threads (only one thread at a time, of course.) Another nice thing is the Buffering stuff, which lets you have a buffer that is on disk as well - it would make producers less needed when sending large amounts of data. It would also improve performance of writing large amounts of data on fast connection, since without producers we can write-at-once. See: http://cvs.zope.org/Zope3/lib/python/Zope/Server/?only_with_tag=Zope-3x-bran... DualModeChannel.DualModeChannel is the sync/async switchable transport. Also, I'm starting to feel jealous of Zope3's amount of unittests...
participants (2)
-
Glyph Lefkowitz -
Itamar Shtull-Trauring