Is crawling the stack "bad"? Why?

Russell Warren russandheather at
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 mailing list