Piotr Stanczyk added the comment:
Thanks Christian for looking into this, please find my responses inlined:
> * IMO it should be called after profiling and tracing hook, so non-trivial
> hooks can be profiled and traced.
Makes sense, Done.
> * It's important to define and document, which thread runs the hook (calling
> thread or new thread).
Will update documentation when we agree upon appropriate API.
> * Since the hook is designed to monitor thread creation, would it make sense
> to pass the thread object to the hook?
As it's called within the context of the created thread I guess this is not
needed (but as you prefer).
> * How does the hook behave when the callback raises an exception?
I guess it makes sense to do similar thing as in case of profile/trace hooks
(Error in the profile function will cause itself unset). WDYT?
> * Is a single hook good enough or should the API behave more like atexit,
> which supports an arbitrary amount of hooks?
Feels like it makes sense to keep API similar to what profile/trace provides,
otherwise it would be inconsistent.
> * Instead of just a creation hook, how about lifetime hooks are also called
> when a thread ends?
Sounds fine, do you mean two independent hooks (_thread_creation_hook,
_thread_termination_hook) or some other form?
--
___
Python tracker
<https://bugs.python.org/issue42443>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
