Is crawling the stack "bad"? Why?
russandheather at gmail.com
Mon Feb 25 08:33:18 CET 2008
> 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
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.
More information about the Python-list