_current_frames is even worse than _getframe

Since it returns a mapping from thread id to the current frame of that thread it would mean that instead of keeping the current frame in a ThreadLocal we will need to keep all frames in a central map. While this could be a ConcurrentMap, and in that case performance would still be scalable (and a lot better than the Jython pre Java1.5 implementation), it would not be as fast as thread local variables.
I also have a hard time to see when this method is useful, by the time you get access to each thread's current frame you have no idea if it is still valid or not. For the current thread you know that it is valid, because you are in the function owning the returned call frame.
It would be interesting to get some pointers to the use cases that lead up to the _current_frames() method.


On Wed, Apr 9, 2008 at 9:07 PM, Frank Wierzbicki <fwierzbicki@gmail.com> wrote:
On Wed, Apr 9, 2008 at 1:13 PM, Brett Cannon <brett@python.org> wrote:
> On Tue, Apr 8, 2008 at 7:32 PM, Frank Wierzbicki <fwierzbicki@gmail.com> wrote:
>  You guys actually support this? Kind of surprised.
>  >   - _getframe
We are not filled with joy about it :) -- but many frameworks use it.

>  Why do you support _getframe and not _current_frame?
I think this is just history.  The production version of Jython is 2.2
and looking at Python's sysmodule.c from way back then looks to me
like _current_frames did not exist yet.  Probably we will implement
_current_frames for the next release.


This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
Jython-dev mailing list