Skip to content

bpo-30766: Make CHECK_STATUS_PTHREAD signal-safe. #2404

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

Closed

Conversation

pitrou
Copy link
Member

@pitrou pitrou commented Jun 26, 2017

No description provided.

@@ -142,9 +142,19 @@ typedef struct {
pthread_mutex_t mut;
} pthread_lock;

#define PUTS(fd, str) _Py_write_noraise(fd, str, (int)strlen(str))
Copy link
Member

Choose a reason for hiding this comment

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

Why casting strlen() to int?

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't know, I copied this macro from traceback.c.

#define CHECK_STATUS_PTHREAD(name) if (status != 0) { fprintf(stderr, \
"%s: %s\n", name, strerror(status)); error = 1; }
/* CHECK_STATUS_PTHREAD is async-signal-safe */
#define CHECK_STATUS_PTHREAD(name) \
Copy link
Member

Choose a reason for hiding this comment

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

I never understood the purpose of these functions. Do we really need these checks? Why not replacing them with an assertion?

If you want to get them at runtime, maybe call Py_FatalError()?

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't know. I'm inclined not to remove them right now.
OTOH, this whole PR may be made obsolete by #2408.

Copy link
Member

Choose a reason for hiding this comment

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

I don't know. I'm inclined not to remove them right now. OTOH, this whole PR may be made obsolete by #2408.

Oh no, please finish your work. I like the idea of more reliable locks :-)

@pitrou
Copy link
Member Author

pitrou commented Jul 18, 2017

I'm inclined to reject this PR. Locks are not signal-safe, so it doesn't make sense to fix a tiny bit of code inside them.

@pitrou pitrou closed this Jul 29, 2017
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.

3 participants