Threads and socketservers... (xmlrpc)

[Magnus Lie Hetland]

I'm writing a simple peer-to-peer system using xmlrpc, and my idea was
to use xmlrpc also for the interaction between the user-interface
(sort of a "client" to one of the "peers/servers" I guess). That's no
problem in itself, but I also wanted to write a standalone program
which starts both a peer node and an ui client. There are, of course,
many ways of doing this -- my first thought was to use fork() or some
friend, but that wouldn't be very Windows friendly. So, I thought,
what about simply using a daemonic thread for the peer/server bit? The
only internal interaction is through xmlrpc anyway (wouldn't have to
be anymore, but...) so synchronisation shouldn't bee much of an issue.
(At least no more than potential deadlocks between two peers.)

However... It seems that this doesn't work very well -- or maybe I'm
doing it wrong. I'm using something like this.

  s = xmlrpclib.Server(...)
  t = threading.Thread(taget=s.serve_forever)
  t.setDaemon(1)
  t.run()
  # Program blocks here...

For some reason the thread seems to hog the process -- the main
program blocks while waiting for the server's accept-loop to
terminate. (The server works just fine, by the way.)

Why is this? Is it because switches can only occur between Python
bytecode instructions and the socket accept stuff is blocking in C?
Shouldn't something like this be possible somehow? After all, the
ThreadingMixin doesn't have any problem with this, does it?

And if I can't use threads like this, are there any other good ways of
doing it (that will work on non-unicen as well)? os.system is a (not
very good) option, perhaps... Hm. (Or writing a custom asynchronous
server :I)

--
Magnus Lie Hetland                                  The Anygui Project
http://hetland.org                                  http://anygui.org