[medusa] Re: [Zope-dev] asynchat producer ready() method patch.

[ender]

On Wednesday 31 January 2001 04:18, Donovan Baarda wrote:
> On Mon, Jan 29, 2001 at 07:26:56PM +0100, Dieter Maurer wrote:
> > Donovan Baarda writes:
> > > On Sun, Jan 28, 2001 at 09:31:07PM +0100, Dieter Maurer wrote:
> > > > Donovan Baarda writes:
> > > > > I remember reading ages ago on a wishlist for ZServer that
> > > > > someone was thinking of adding blocking support to producers.
> > > > > This patch adds support for just that in a non-intrusive way. I
> > > > > haven't tried applying this patch to ZServer, but it _should_
> > > > > work.
> > > >
> > > > What does "blocking support dor producers" mean?
> > >
> > > Disclaimer: you must be moderately familiar with
> > > ZServer/medusa/asynchat for the following to make sense;
> > >
> > > Asynchat used by ZServer and medusa use producers as a way to "push"
> > > data through an async interface. The current version of asynchat
> > > requires that producers be able to produce data immediately on calling
> > > their more() method, untill they are finished, when they return ''.
> > >
> > > My patch adds support for producers being able to "block" by letting
> > > asynchat know if they are ready via a ready() method. This allows you
> > > to use the simple producer model to push data that may not be
> > > immediately available. An example would be a http-fetch producer that
> > > fetches data from upstream for a proxy.
> > >
> > > This patch is only useful for people creating or modifying things like
> > > medusa or ZServer.
> >
> > Thank you for this good explanation.
> >
> > By now, I think, it would not be usefull for ZServer, at least
> > not for standard operations.
> >
> > ZServer is a multi-threaded server, where different requests
> > are serviced by different threads.
> > The thread may block and does simply not return from "more()".
> >
> > On first thought, you patch might free some blocked threads
> > to do productive work. However, Zope's transaction system
> > is linked to thread management. If you patch would be used
> > for that, Zope's transaction subsystem would need to be
> > rewritten.
>
> Hmmm, it's been a while since I looked at ZServer, I might have to take
> another look. I thought that it pre-spawned a number of threads that each
> ran their own asyncore.loop event handler. I thought this was a neat way to
> get the benefits of async event handlers and distributing threads on
> multiple processors. Unless it spawns new threads when it needs them, it
> would still be possible for ZServer to get blocked if all the threads were
> blocked.

disclaimer: insert here.

zserver has a main thread which binds and listens, passing requests to a pool 
of zpublisher threads. the zpublisher threads communicate with the client via 
the main threads dispatcher, ie output is funneled back into the main 
thread's dispatcher so as not to tie up threads talking to distant clients.

reference: Zserver/medusa/select_trigger.py

python has a global interpreter lock, so multiple cpus have little utility. 


> However, my patch is only useful if you _have_ producers that can block. It
> is usually possible to re-structure your system so that no producers block
> (typicaly by using a dispatcher instead of a producer). The ready() block
> feature is really a shortcut way of modifying an existing producer-based
> design when you realise that the producer can block; ie an alternative way
> of implementing it that may or may not be better.


i've taken a quick look at the patch, i find it interesting in that it 
provides i think a way to implement a Proactor type server vs the standard 
medusa Reactor style server.

reference: Patterns of System Architecture Vol II. Douglas Schmidt et al
reference: http://www.cs.wustl.edu/~schmidt/PDF/proactor.pdf

and a webserver that makes use of this pattern
http://www.cs.wustl.edu/~jxh/research/


kapil


> In my case I wanted to create a cached-ftp-backend filesystem that medusa
> could serve via ftp or http. Unfortunately the existing ftp and http server
> implementations used producers to pull data from the abstract filesystem.
> Since my "filesystem" could block pretty severly, I either needed to
> completely re-write the http and ftp servers to use dispatchers instead of
> producers, or implement blocking for producers (or use a seperate thread
> for each request, but I thought that defeated the purpose of using an async
> event loop).



> I really must look at ZServer to figure out how it handles things... I
> suspect that my patch by itself would not _hurt_ ZServer, but perhaps if
> you started using the ready() feature it provides it might cause problems.
> I'll have a look at ZServer again soon and give you an evaluation of how my
> patch would interact with it.

> Who knows, someone might find a need for blocking producers as ZServer
> evolves, and if people know the patch exists, they might use it instead of
> re-structuring to get around it :-)