[Twisted-Python] (Un)Twisted Clients and Servers (newbie)

[Bill la Forge]

Bob,

Thanks for the feedback. Is Zope3 stackless? Or did I
misread that somewhere?

The old unix model of processes/pipes keeps coming 
back up, it seems. Occum made good use of it, and I
understand stackless does too. I think its the
ultimate
component model.

Just a side note, bsddb apparently doesn't care which
thread you use, as long as its sequential. This 
apparently changed (at least in the docs) in 4.2
(which is included with Python 2.3). (And was pointed
out to me a few days ago on this list!)

I agree that Python, being already a high-level 
language, is likely not the best choice for layering
another programming model on top of. And stackless
looks like its a speed Phreek's dream. Where's the
documentation for Stackless, in the download? I'd
like to read more about it than what I can find on
the web site.

Anyway, I've picked my horse--Medusa--and I had 
intended to ride it for a while. But Twisted looked
far richer/active/maintained. Is the world really
ready for Stackless? It could be a far better world...

(It really wouldn't take much to get me over there,
but I really really need a lot of what's already 
part of Twisted!)

Bill

 --- Bob Ippolito <bob at redivi.com> wrote: > On May 26,
2004, at 8:26 AM, Bill la Forge wrote:
> 
> > Finally wrote my first Twisted-based client and
> > server:
> >
> http://compstrm.sourceforge.net/twcs/csprotocol.html
> >
> > Both the client and server are implemented as
> light-
> > weight processes, where pipes are used for reading
> > and writing to remote processes. This allows the
> > logic flow to be more straight-line.
> >
> > I'm also "translucently" switching threads in the
> > client, using in-line method calls, so that reads
> > and writes to the client do not block the main
> thread.
> >
> > (I'm trying to show how much clearer asynchronous
> > programming can be using Computational Streams.)
> 
> You really need to take a look at Stackless Python. 
> It's a much better 
> fit for the programming paradigm you want, and
> tasklet communication is 
> WAY faster than thread communication in Python.  I
> also think that the 
> Communicating Sequential Processes model is much
> nicer than your 
> Computational Streams model.
> 
> As far as switching between "async" and 'blocking",
> why don't you just 
> yield BlockingMode and yield AsyncMode?  That would
> kill two birds with 
> one stone.  What's the difference between yielding
> True, False, and 
> None (that is rhetorical, I read the
> implementation)?  Personally I 
> think you should use useful names, even if they are
> just aliases for 
> built-in python datatypes.  For example, the
> following lines are much 
> more self-documenting:
> 
> yield Cooperate
> yield Stop
> yield BlockingMode
> yield AsyncMode
> 
> When I did a framework very similar to but much more
> simple than yours, 
> I also made it possible to integrate with Deferred
> (to block on it and 
> resume on success/err, and also to return a deferred
> instead of a 
> generator using a function wrapper).
> 
> Translucent thread migration isn't the greatest
> idea, sometimes you 
> need to tie data structures to the a threadstate
> (for C level code.. 
> something like database cursors, or whatever).  It's
> usually better to 
> keep the same code on the same thread whenever
> possible.  But of 
> course, it's better just to not use them at all
> unless you are calling 
> some blocking C code, because it doesn't do anything
> for you with 
> Python bytecode.
> 
> -bob


________________________________________________________________________
Yahoo! India Matrimony: Find your partner online. http://yahoo.shaadi.com/india-matrimony/