[Python-Dev] Obtaining stack-frames from co-routine objects

jaivish kothari jaivishkothari10104733 at gmail.com
Sat Jun 13 12:38:05 CEST 2015


Hi ,

   I had a Question,i hope i'll find the solution here.

Say i have a Queue.
 >>> h = Queue.Queue(maxsize=0)
>>> h.put(1)
>>> h.put(2)
>>> h.empty()
False
>>> h.join()
>>> h.empty()
False
>>> h.get()
1
>>> h.get()
2
>>> h.get()
Blocked.......................

My Question is :
In a single threaded environment why does the get() gets blocked , instead
of raising an exception.On interpreter i have no way to resume working.

And my second question is :
Why doe we have to explicitly call task_done after get(). why doesn't get()
implicitly call task_done().
as for put() entry for unfinished_task is automatically added .why not get
deleted in get() then.

Thanks.

On Fri, May 29, 2015 at 10:16 AM, Ben Leslie <benno at benno.id.au> wrote:

> Hi all,
>
> Apologies in advance; I'm not a regular, and this may have been
> handled already (but I couldn't find it when searching).
>
> I've been using the new async/await functionality (congrats again to
> Yury on getting that through!), and I'd like to get a stack trace
> between the place at which blocking occurs and the outer co-routine.
>
> For example, consider this code:
>
> """
> async def a():
>     await b()
>
> async def b():
>     await switch()
>
> @types.coroutine
> def switch():
>     yield
>
> coro_a = a()
> coro_a.send(None)
> """
>
> At this point I'd really like to be able to somehow get a stack trace
> similar to:
>
> test.py:2
> test.py:4
> test.py:9
>
> Using the gi_frame attribute of coro_a, I can get the line number of
> the outer frame (e.g.: line 2), but from there there is no way to
> descend the stack to reach the actual yield point.
>
> I thought that perhaps the switch() co-routine could yield the frame
> object returned from inspect.currentframe(), however once that
> function yields that frame object has f_back changed to None.
>
> A hypothetical approach would be to work the way down form the
> outer-frame, but that requires getting access to the co-routine object
> that the outer-frame is currently await-ing. Some hypothetical code
> could be:
>
> """
> def show(coro):
>     print("{}:{}".format(coro.gi_frame.f_code.co_filename,
> coro.gi_frame.f_lineno))
>     if dis.opname[coro.gi_code.co_code[coro.gi_frame.f_lasti + 1]] ==
> 'YIELD_FROM':
>         show(coro.gi_frame.f_stack[0])
> """
>
> This relies on the fact that an await-ing co-routine will be executing
> a YIELD_FROM instruction. The above code uses a completely
> hypothetical 'f_stack' property of frame objects to pull the
> co-routine object which a co-routine is currently await-ing from the
> stack. I've implemented a proof-of-concept f_stack property in the
> frameobject.c just to test out the above code, and it seems to work.
>
> With all that, some questions:
>
> 1) Does anyone else see value in trying to get the stack-trace down to
> the actual yield point?
> 2) Is there a different way of doing it that doesn't require changes
> to Python internals?
> 3) Assuming no to #2 is there a better way of getting the information
> compared to the pretty hacking byte-code/stack inspection?
>
> Thanks,
>
> Ben
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/jaivishkothari10104733%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150613/1588f17f/attachment.html>


More information about the Python-Dev mailing list