Questions about asyncore

Giampaolo Rodola' gnewsg at
Wed Jul 30 19:50:34 CEST 2008

On 30 Lug, 09:49, Frank Millman <fr... at> wrote:
> On Jul 29, 3:40 pm, "Giampaolo Rodola'" <gne... at> wrote:
> > On 29 Lug, 13:09, Frank Millman <fr... at> wrote:
> Thanks for the reply, Giampaolo.

Glad to help.

> > The benefit of asynchat is that it automatically handles the buffering
> > of both input and output.
> > Aside from set/found_terminator() the other two methods you could want
> > to look at are push() and push_with_producer().
> > push() is a buffered version of asyncore.send(), push_with_producer()
> > accepts a data-producer object you can use in case you want to deal
> > with something other than strings (e.g. files, lists, generators, and
> > so on...).
> I looked at push() and push_with_producer(). To be honest I don't
> fully understand why I would want to use them yet - I will have to go
> over them a few more times. However, my handle_write() method seems to
> be working ok and is not complicated, so I will stick with that for
> now.

I don't know whether you need to use them. I've just introduced the
benefits of asynchat over asyncore.
If you're already ok with your handle_read() implementation you
probably don't need anything different.

> > I'm not sure to understand but I doubt you have to use a thread.
> > If you "have to wait for the reply before continuing" just implement
> > this logic into handle_read() or found_terminator() method.
> Maybe I am a bit slow

Or maybe my English is not good enough to properly understand what you
need (it wouldn't be the first time, after all... =)).

> ...but I cannot figure out how to do this without
> adding a lot of complication. I will try to give a simple example.
> My server is a database server. It sits between the actual database
> and the client, and implements access control, automatic handling of
> foreign keys, etc. It accepts messages to read, update, and write
> data, and returns the results.
> For testing purposes, I want the client to send and receive messages
> such as the following (pseudocode) -
> -> Read Customer record with CustNo = 'A001'.
> <- Print data, check that it is correct. [1]
> -> Read customer's Branch record.
> <- Print data, check that it is correct.
> -> Update Customer record with new Branch code. [2]
> -> Read Branch code from Customer record.
> <- Print code, check that it has changed.
> -> Read customer's Branch record.
> <- Print data, check that it belongs to the new Branch.
> [1] Amongst other things, the server returns the id of the record
> [2] The update request uses the record id to identify which record to
> update
> These are just examples of the tests I might want to throw at the
> server. With my multi-threaded approach, the asyncore loop runs in the
> background, and in the foreground I can easily send any message I like
> and check the results. I cannot see how to implement this using
> handle_read() and found_terminator().
> Maybe you can give a simple example of an alternative approach.
> Thanks
> Frank

I pretty much have the same overview I had before.
As far as I can tell the only reason you want to use a thread is when
you have to do something which requires a consistent amount of time to
complete so that the asyncore loop gets blocked.
The question is: is there anything like that in your code?
If the answer is no then you don't need to use threads.
Maybe you are just not used to the asynchronous approach where "wait
for server to respond" or "wait for the response to be complete"
doesn't mean that YOU have to wait.
It means that when a specific condition occurs (e.g. some data is
received) a certain method of the framework you're using will be
called and then it will be up to you deciding what do to.
For example, if you're supposed to do something when a string of 5
digits is received, overwrite the handle_read() method and check if
that's happened.
If not instead of waiting for it to happen just "pass" and wait for
handle_read() to be called again.
This way you don't do anything which blocks the asynchronous loop and
every peer (clients, servers or both) you have in your list of
watchable channels will be served.

If my response hasn't helped you any further try to post some code so
that me or someone else could see what exactly you're trying to do.
Hope this helps, anyway.

--- Giampaolo

More information about the Python-list mailing list