Questions about asyncore

Giampaolo Rodola' gnewsg at gmail.com
Thu Jul 31 16:39:22 EDT 2008


On 31 Lug, 08:30, Frank Millman <fr... at chagford.com> wrote:
> On Jul 30, 7:50 pm, "Giampaolo Rodola'" <gne... at gmail.com> wrote:
>
> > On 30 Lug, 09:49, Frank Millman <fr... at chagford.com> wrote:
>
> Thanks again, Giampaolo, your input is really appreciated.
>
>
>
> > 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.
>
> Maybe I am not being clear enough on my side.
>
> I (hope I) understand the power of asnyc. I have written the server to
> use async techniques, and when I get around to writing the full-blown
> client, that will also use async techniques.
>
> However, at this stage, all I want to do is write something quick and
> dirty to check that the server is behaving as intended. I want to
> throw some messages at it, more or less at random, and check the
> responses. I found it much easier to do this with asyncore.loop
> running in a separate thread.

I don't know why you find more convenient running asyncore.loop in a
separate thread but if your purpose is writing a test suite in which a
client checks responses sent by server I *would not* recommend using
asyncore.
The common way to do that is starting the server into setUp() method
and shut it down in tearDown().
Every test consists in a client which uses the socket module to
connect() to the server, send() something and recv() the response.
That's all.
pyftpdlib, which consists of an asyncore-based FTP server, has a test
suite behaving exactly like that.
Try to take a look and see if it could fit your purposes:
http://code.google.com/p/pyftpdlib/source/browse/tags/release-0.4.0/test/test_ftpd.py

> To send a message from the main thread, I append it to a list called
> self.sendData. In asyncore.dispatcher, writable() returns True if the
> list contains anything, and handle_write() pops the message off the
> list and sends it.
>
> To receive messages, readable() always return True, and handle_read()
> breaks up the input into individual messages and appends them to a
> list called self.recvData. When the main thread is waiting for a
> response, it simply loops until self.recvData contains something.
>
> To do this asynchronously, for every test I would have to define the
> detailed interaction between client and server, and write methods to
> be called from within handle_read(). It could be done, but it would be
> much more tedious.
>
> Does this make sense?

Now I see why you find it more tedious, in fact I wouldn't use that
kind of approach in the test suite.
Anyway, I still don't understand why running asyncore.loop into a
thread could make any difference.


--- Giampaolo
http://code.google.com/p/pyftpdlib/



More information about the Python-list mailing list