Modification to asyncore.py to support threaded event loop

[Anand Pillai]

I tried your code and this is the result...


Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 436, in __bootstrap
    self.run()
  File "/usr/lib/python2.3/threading.py", line 416, in run
    self.__target(*self.__args, **self.__kwargs)
  File "urlserver.py", line 205, in asyncore_loop
    map = asyncore.map
AttributeError: 'module' object has no attribute 'map'

asyncore does not have an attribute named 'map', only socket_map.
'map' is an argument to ascynore.loop function, again not its
attribute.

Did you try this code out before posting it here? 

Also, asyncore.loop has a while loop inside it, and you are adding
another while loop on top. Clearly your exit condition, if it works is
going to only exit the outer while loop, not the inner one. I dont
think it is going to work.


-Anand

Josiah Carlson <jcarlson at uci.edu> wrote in message news:<mailman.5924.1099592900.5135.python-list at python.org>...
> abpillai at gmail.com (Anand Pillai) wrote:
> > 
> > If you have ever used the asyncore module, you will realize that it's
> > event loop does not have a programmable exit condition. It keeps
> > looping till the channels in its socket map (a dictionary) are closed
> > and don't have any pending reads/writes.
> 
> With the asyncore that will be included with Python 2.4, loop() has a
> 'count' argument.  Your 'programmable exit condition' is simple...
> 
> while not exit_condition_satisfied:
>     asyncore.loop(count=1)
> 
> 
> > If you are using Python threads in your application, by using either
> > the threading or thread modules, adding asyncore capability on top of
> > it is a bit tricky. The moment you call asyncore.loop after
> > initializing your asyncore based client/server, it takes over the main
> > thread. Hence, if you want to mix threaded classes (derived from
> > threading.Thread) and asyncore in one program, the only recourse is to
> > create and initialize all your thread objects first and call
> > asyncore.loop as the last function in your main thread.
> > 
> > However, with a small hack it is possible to get asyncore event loop
> > running in its own thread, as shown below.
> 
> Here's an easier way to get asyncore running in its own thread, with
> nearly all the functionality you mention, without having to subclass
> Thread.
> 
> def asyncore_loop(exit_condition, timeout=30.0,
>                   use_poll=False, map=None):
>     if map is None:
>         map = asyncore.map
>     while map and not exit_condition:
>         asyncore.loop(timeout=30.0, use_poll=False, map=map, count=1)
> 
> exit_condition = []
> 
> threading.Thread(target=asyncore_loop, args=(exit_condition,)).start()
> 
> #to kill the thread...
> exit_condition.append(None)
> 
> 
> > The following is a mixin class, which derives from threading.Thread
> > and also overrides asyncore.loop in its 'run()' method.
> 
> [snip unnecessary code]
> 
> > Now you can initialize your asyncore based clients/servers and instead
> > of calling 'asyncore.loop', do it as follows,
> 
> See the snippet I provide above.
> 
> 
> > Perhaps this is worth a PEP for inclusion in Python 2.4?
> 
> Module and/or functionality additions do not require a PEP (from what I
> understand).  Changing the behavior of the language, adding a builtin,
> etc., that requires a PEP.
> 
> It is not going to make it into Python 2.4.  How would I know this? 
> Because "no new functionality after the beta".  We're on beta 2, and
> even small functionality additions that were pre-approved (but not
> implemented) are not making it into 2.4.
> 
> What about for Python 2.5?  I doubt it would be added there either.  The
> functionality is very simple to implement if you know what you are doing,
> and doesn't require copying the internals of asyncore.loop to make it
> happen.
> 
>  - Josiah