Piotr Stanczyk <stanc...@google.com> 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 <rep...@bugs.python.org> <https://bugs.python.org/issue42443> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
