W.: W.: Re: [Stackless] problem with Plone (in Zope) and stackless python

[taskless at arcor.de]

> 
> No, but it is still implemented on top of asyncore.
> And writing asyncore using tasklets and channels
> is the work of a day. I did that already, but as
> paid work, I cannot give it away.
> 
> ciao - chris
> 

Hello Chris

You are a bit mysterious about what you did in your version of asyncore. Below is 
my guessing of what you propose:
- You want to have Zope create tasklets instead of threads, so that it appears for 
    Zope that it is running in several threads, but in fact it will run in several 
    tasklets of the same thread
- Each Zope tasklet uses your stackless version of asyncore, receiving all incomming traffic 
    from a single in-channel and sending all outgoing traffic to a single out-channel
- You have a special tasklet (presumably the main tasklet) dedicated to feeding the 
    in-channel with events on the sockets and writing to them the messages received 
    on the out-channel 
    
But how about disk I/O? Is ZODB also based on asyncore? How about Zope's usage 
of relational databases? Are the database libraries based on asyncore?
I doubt. 
(I would be glad to get answers based on knowledge instead of my guesses, anyone to help?)
I guess that disk I/O and database operations do block the performing *thread* (and not only the 
performing tasklet), with or without a Stackless based asyncore module, simply because they
use synchronous, blocking I/O, and not asyncore.

On one hand, the strenght of stackless is that it offers a way to avoid blocking 
your threads. On the other hand, the original asyncore implementation already provides 
non-thread-blocking I/O on sockets. 

My point is that rewriting asyncore so that it handles Stackless channels does not help Zope, rewriting ZODB or rewriting the DB libraries (or more pragmatically, writing stackless-based interfaces to them) would.

I think providing an asyncore-compliant event-driven programing interface
to the stackless.channel-based communication facility among tasklets is still a good idea:
it would complement the exclusively synchronous "send" and "receive" channel operations
(ideal for non-event-driven, sequential programs) with asynchronous event detection, allowing
existing event-driven programs (perhaps written originally to handle sockets) to
handle stackless.channels. 

Even more valuable would be to rewrite the traditionally thread-blocking operations of I/O objects
(e.g. read/write/flush etc. operations of the built-in file object, socket objects, etc.)
so that they block the calling tasklet, but not the thread! A tasklet-blocking version 
(as opposed to its original thread-blocking version) of "sleep" would be welcome as well.
 
Of course I do not expect you to write all of these ...

Regards

Denes



_______________________________________________
Stackless mailing list
Stackless at stackless.com
http://www.stackless.com/mailman/listinfo/stackless