Now that you're correctly using int, reading/writing it may no longer be atomic. So you should use the atomic macros to access it (there are plenty of examples in signalmodule.c doing that).

Thanks for your comment, now the fd is not atomic, do you mean I also still use _Py_atomic_load() or _Py_atomic_store() to read/write it ?

Thanks very much

Please open a separated issue for this change.

Thanks for your comment, now the fd is not atomic, do you mean I also still use _Py_atomic_load() or _Py_atomic_store() to read/write it ?

Yes, I think so. You'll find many uses of these functions in signalmodule.c.

The easiest way to fix VxWorks but not impact other operating systems if to modify your PR as, pseudo-code:

#ifdef <VxWorks>
int ...
#else
sig_atomic_t ...
#endif

The existing code is unconditionally wrong: it's a file descriptor, which is of type int.

The existing code is unconditionally wrong: it's a file descriptor, which is of type int.

I already asked "Please open a separated issue for this change." but nobody did that.

I already asked "Please open a separated issue for this change." but nobody did that.

I know but that doesn't imply that the existing code is correct. It only means that nobody cares enough to open an issue.

It only means that nobody cares enough to open an issue.

In case of doubt, I'm ok to leave the code unchanged: that's the safest option. That's the principle of https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence To remove the fence, someone must first investigate why it's there.

This issue is about VxWorks. I disagre that adding VxWorks support would change the code on other platforms.

Let's continue the work on PR #23391.