> That is just madness. What specifically makes it madness? Is it because sys._frame is "for internal and specialized purposes only"? :)
> The incoming ip address is available to the request handler, see the > SocketServer docs I know... that is exactly where I get the address, just in a mad way. > Write a request handler that stashes that info somewhere that rpc > responders can access it in a sane way. That is exactly where I started (creating my own request handler, snagging the IP address and stashing it), but I couldn't come up with a stash location that would work for a threaded server. This is the problem I was talking about with the "current_peer_info" scheme. How is the RPC responder function supposed to know what is the right stash, given that when threaded there could be multiple stashes at a time? The IP needs to get down to the exact function execution that is responding to the client... how do I do that? I had my options as: 1) stash the IP address somewhere where the RPC function could get it 2) pass the IP down the dispatch chain to be sure it gets to the target I couldn't come up with a way to get 1) to work. Then, trying to accomplish 2) I reluctantly started messing with different schemes involving my own versions of do_POST, _marshaled_dispatch, and _dispatch in order to pass the IP directly down the stack. After some pain at this (those dispatches are weird) I decided it was waaaay too much of a hack. Then I thought "why not go up the stack to fetch it rather than trying to mess with the nice/weird dispatch chain to send it down". I now had a third option... 3) Go up the stack to fetch the exact IP for the thread After realizing this I had my working stack crawl code only a few minutes later (I had GetCallerNameAndArgs already). Up the stack has a clear path. Down was murky and involved trampling on code I didn't want to override. The results is much cleaner than what I was doing and it worked, albeit with the as yet unfounded "crawling the stack is bad" fear still there. I should also point out that I'm not tied to SimpleXMLRPCServer, it is just a convenient example. I think any RPC protocol and dispatcher scheme would have the same problem. I'd be happy to hear about a clean stashing scheme (or any other alternative) that works for a threaded server. My biggest specific fear at the moment is that sys._frame will do funky things with multiple threads, but given that my toy example is executing in a server on its own thread and it traces perfectly I'm less worried. Come to think of it, I wonder what happens when you crawl up to and past thread creation? Hmm. -- http://mail.python.org/mailman/listinfo/python-list
