Multithreaded Medusa
Itay Zandbank
zmbq@a...
Wed, 4 Oct 2000 17:53:24 +0300
---------------------- multipart/alternative attachment
Aside from stalled producers, I also needed to multi-thread Medusa. I hav=
e a proxy server, that does some processing on the passing data. This proce=
ssing is pretty quick. Quick enough to put in the main select thread withou=
t slowing things down (the overhead of delegating the job to another thread=
, even if that thread is already running, is not worth it). The problem is =
with multi-CPU machines. On a machine with two CPUs, having two threads can=
have a drastic impact on performance.
What I came up with, then, was this: Have one thread listening for incomi=
ng connections, and one (or more, depending on the number of CPUs you have)=
process these connections. The theory seemed easy enough. But then reality=
hit me. Since I have two (or more) threads working on network connections,=
I need two select loops, and more importantly, two socket_maps.
All throughout Medusa, there's code that assumes the socket map is asynco=
re.socket_map (in http_server, for instance). What I had to do eventually, =
was create a class (I called it Redirector), which has two methods - add_ch=
annel and del_channel, which put the socket in the right socket_map, like t=
his:
class Redirector:
def __init__(self, socket_map):
self.socket_map =3D socket_map
def add_channel(self, map=3DNone):
if map is None:
map =3D self.socket_map
asynccore.dispatcher.add_channel(self, map)
def del_channel(self, map=3DNone):
# Very much like add_channel
Each time I have an asyncore.dispatcher derived class in my souce, I also=
derive it from Redirector.
This works, but it's really ugly (I'm sure that in a month, I'll spend an=
entire week tracking down a bug caused by not deriving a class from Redire=
ctor). It would have been much better if asyncore.dispatcher had a socket_m=
ap member in the first place. The default can still be the global socket_ma=
p, so no code will break.
Thanks again,
Itay.
---------------------- multipart/alternative attachment
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail-21/medusa-dev/attachments/adfe8fd7/attachment.html
---------------------- multipart/alternative attachment--