>
> > Seriously, crawling the stack introduces the potential for disaster in
> > your program, since there is no guarantee that the calling code will
> > provide the same environment i future released. So at best you tie your
> > solution to a particular version of a particular implementation of
>
>
> I will (mostly)... I knew it was bad code and a total hack, I just was
> looking for a concise reason as to why.
>
> I appreciate the comments, guys... thanks!
There is another one: crawling the stack is O(n), whilst using
thread-local storage is O(1)
Diez
--
http://mail.python.org/mailm
> OK, if you crawl the stack I will seek you out and hit you with a big
> stick. Does that affect your decision-making?
How big a stick? :)
> Seriously, crawling the stack introduces the potential for disaster in
> your program, since there is no guarantee that the calling code will
> provide the
Paul Rubin wrote:
> Russell Warren <[EMAIL PROTECTED]> writes:
>> 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.
>
> How about a dictionary indexed
Russell Warren wrote:
> Thanks Ian... I didn't know about threading.local before but have been
> experimenting and it will likely come in quite handy in the future.
> For this particular case it does basically seem like a replacement for
> the threadID indexed dictionary, though. ie: I'll still ne
Thanks Ian... I didn't know about threading.local before but have been
experimenting and it will likely come in quite handy in the future.
For this particular case it does basically seem like a replacement for
the threadID indexed dictionary, though. ie: I'll still need to set
up the RpcContainer,
On 2008-02-25, Russell Warren <[EMAIL PROTECTED]> wrote:
>
>> the threading.local class seems defined for that purpose, not that I've ever
>> used it ;)
>
> I hadn't heard of that... it seems very useful, but in this case I
> think it just saves me the trouble of making a stash dictionary...
> unle
> How about a dictionary indexed by by the thread name.
Ok... a functional implementation doing precisely that is at the
bottom of this (using thread.get_ident), but making it possible to
hand around this info cleanly seems a bit convoluted. Have I made it
more complicated than I need to? There
Paul Rubin wrote:
> Russell Warren <[EMAIL PROTECTED]> writes:
>> 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.
>
> How about a dictionary indexed
Russell Warren <[EMAIL PROTECTED]> writes:
> 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.
How about a dictionary indexed by by the thread name. It
> 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 wa
That is just madness. The incoming ip address is available to the
request handler, see the SocketServer docs. Write a request handler
that stashes that info somewhere that rpc responders can access it in
a sane way.
--
http://mail.python.org/mailman/listinfo/python-list
Argh... the code wrapped... I thought I made it narrow enough. Here
is the same code (sorry), but now actually pasteable.
---
import SimpleXMLRPCServer, xmlrpclib, threading, sys
def GetCallerNameAndArgs(StackDepth = 1):
"""This function returns a tuple (a,b) where:
a = The name of the ca
I've got a case where I would like to know exactly what IP address a
client made an RPC request from. This info needs to be known inside
the RPC function. I also want to make sure that the IP address
obtained is definitely the correct one for the client being served by
the immediate function call
14 matches
Mail list logo
