Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bpo-41435: Add sys._current_exceptions() function #21689

Merged
merged 1 commit into from Nov 2, 2020

Conversation

jd
Copy link
Contributor

@jd jd commented Jul 30, 2020

This adds a new function named sys._current_exceptions() which is equivalent ot
sys._current_frames() except that it returns the exceptions currently handled
by other threads. It is equivalent to calling sys.exc_info() for each running
thread.

https://bugs.python.org/issue41435

@gvanrossum
Copy link
Member

gvanrossum commented Aug 3, 2020

This is a fantastic idea. I don't have time to review it but hopefully @serhiy-storchaka can have a look.

@gvanrossum gvanrossum requested a review from serhiy-storchaka Aug 3, 2020
Copy link
Member

@serhiy-storchaka serhiy-storchaka left a comment

I am not sure that adding sys._current_exceptions() is the best solution.

Python/pystate.c Outdated
@@ -1195,6 +1195,66 @@ _PyThread_CurrentFrames(void)
return result;
}

/* The implementation of sys._current_exceptions(). This is intended to be
called with the GIL held, as it will be when called via
sys._current_frames(). It's possible it would work fine even without the GIL
Copy link
Member

@serhiy-storchaka serhiy-storchaka Aug 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have doubts that it would work fine without the GIL held because of: 1) auditing, 2) memory allocation.

Copy link
Contributor Author

@jd jd Aug 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I copy/pasted the comment from sys._current_frames since they use the same mechanism. I can also factor the code and the comment elsewhere.

Copy link
Member

@vstinner vstinner Sep 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You must not use the Python C API without holding the GIL: PyLong_FromUnsignedLong(), PyDict_SetItem(), etc. require to hold the GIL.

Copy link
Contributor Author

@jd jd Sep 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, we might want to update the comment for _current_frames then!

Python/pystate.c Show resolved Hide resolved
@jd jd force-pushed the sys-current-exceptions branch from 454c7c3 to 789d9b0 Compare Aug 3, 2020
@gvanrossum
Copy link
Member

gvanrossum commented Aug 3, 2020

@serhiy-storchaka

I am not sure that adding sys._current_exceptions() is the best solution.

What would you propose? The use case is real.

@jd jd force-pushed the sys-current-exceptions branch from a2d698c to e21084d Compare Aug 7, 2020
@serhiy-storchaka
Copy link
Member

serhiy-storchaka commented Aug 7, 2020

I do not know what the use case is exactly (I also do not know the use case of sys._current_frames()). I am wondering if adding methods or properties for getting current handled exception for specified frame or thread would be more general solution.

@jd
Copy link
Contributor Author

jd commented Aug 7, 2020

In my case, the use-case for both functions is to be able to do statistical profiling on programs and to learn which code paths are raising the most exceptions, which type of exceptions, etc.

We do this currently in a hacky way with Cython and -DPy_BUILD_CORE: https://github.com/DataDog/dd-trace-py/blob/master/ddtrace/profiling/collector/stack.pyx#L301-L323

You can look at what Java and JFR do in this regard for example: https://stackoverflow.com/questions/60147519/how-to-profile-the-number-of-exceptions-generated-categorized-by-exception-clas

@jd
Copy link
Contributor Author

jd commented Aug 25, 2020

@serhiy-storchaka Does that make a compelling argument? :)

@jd
Copy link
Contributor Author

jd commented Sep 15, 2020

@vstinner any opinion on this?

try:
raise ValueError("oops")
except ValueError:
if leave_g.wait(timeout=0.1):
Copy link
Member

@vstinner vstinner Sep 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer to use support.SHORT_TIMEOUT or even support.LONG_TIMEOUT if the timeout should not occur.

Copy link
Contributor Author

@jd jd Sep 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

PyObject *
_PyThread_CurrentExceptions(void)
{
PyThreadState *tstate = _PyThreadState_GET();
Copy link
Member

@vstinner vstinner Sep 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer to ensure that the GIL is held. For example, call _Py_EnsureTstateNotNULL(tstate).

Copy link
Contributor Author

@jd jd Sep 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

Python/pystate.c Outdated
@@ -1195,6 +1195,66 @@ _PyThread_CurrentFrames(void)
return result;
}

/* The implementation of sys._current_exceptions(). This is intended to be
called with the GIL held, as it will be when called via
sys._current_frames(). It's possible it would work fine even without the GIL
Copy link
Member

@vstinner vstinner Sep 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You must not use the Python C API without holding the GIL: PyLong_FromUnsignedLong(), PyDict_SetItem(), etc. require to hold the GIL.

/*[clinic input]
sys._current_exceptions

Return a dict mapping each thread's thread id to its current raised exception.
Copy link
Member

@vstinner vstinner Sep 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-thread

=> thread's identifier

Copy link
Contributor Author

@jd jd Sep 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

if (err_info == NULL) {
continue;
}
PyObject *id = PyLong_FromUnsignedLong(t->thread_id);
Copy link
Member

@vstinner vstinner Sep 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A single thread can be associated to more than one Python thread state. It is possible that two interpreters run in the same thread, just not at the same time.

Copy link
Contributor Author

@jd jd Sep 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is also a limitation in _current_frames then, right?
I think it'd be fine in this case to mimic what _current_frames does in this regard.

.. function:: _current_exceptions()

Return a dictionary mapping each thread's identifier to the topmost exception
currently active in that thread at the time the function is called.
Copy link
Member

@vstinner vstinner Sep 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not clear that threads with no exception are omitted in this dictionary.

Copy link
Contributor Author

@jd jd Sep 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@jd jd force-pushed the sys-current-exceptions branch from e21084d to 62f48e2 Compare Sep 28, 2020
@jd jd requested a review from vstinner Sep 28, 2020
@jd jd force-pushed the sys-current-exceptions branch 2 times, most recently from eeed951 to ae0e5d7 Compare Sep 28, 2020
@vstinner
Copy link
Member

vstinner commented Oct 6, 2020

cc @markshannon @scoder

Python/pystate.c Outdated
goto fail;
}
PyObject *exc_info = PyTuple_Pack(3,
err_info->exc_type != NULL ? err_info->exc_type : Py_None,
Copy link
Member

@serhiy-storchaka serhiy-storchaka Oct 14, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These lines are too long. I propose to reduce indentation,

Copy link
Contributor Author

@jd jd Oct 14, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, re-indented.

This adds a new function named sys._current_exceptions() which is equivalent ot
sys._current_frames() except that it returns the exceptions currently handled
by other threads. It is equivalent to calling sys.exc_info() for each running
thread.
@jd jd force-pushed the sys-current-exceptions branch from ae0e5d7 to 0726d17 Compare Oct 14, 2020
@jd
Copy link
Contributor Author

jd commented Nov 2, 2020

Can someone press the button?
cc @serhiy-storchaka @vstinner

@serhiy-storchaka serhiy-storchaka merged commit 64366fa into python:master Nov 2, 2020
3 checks passed
adorilson pushed a commit to adorilson/cpython that referenced this pull request Mar 13, 2021
This adds a new function named sys._current_exceptions() which is equivalent ot
sys._current_frames() except that it returns the exceptions currently handled
by other threads. It is equivalent to calling sys.exc_info() for each running
thread.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants