-
Notifications
You must be signed in to change notification settings - Fork 123
Internal Refactoring for better thread safety #4861
Comments
Yes, that seems like a pretty good showcase example.
If you're using TOML and see it as an important problem, why not create a PR yourself? The issue already suggests what needs to be done and it shouldn't be too hard to do. In any case, even if this could be automated, I think doing it by hand is much quicker and easier.
Finding global variables should work with plain |
Moved to #4870 (comment) |
Moved to #4869 (comment) |
I mark this stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping by writing a message here or create a new issue with the remainder of this issue. |
I closed this now because it has been inactive for more than one year. If I closed it by mistake, please do not hesitate to reopen it or create a new issue with the remainder of this issue. |
As the API discussions are still ongoing and an agreement on the full API will probably take some time (I still suggest to pick smaller changes which have a clear problem), I suggest that you start with internal refactoring to get the development of the refactoring tool going so that we see what it actually can do.
Following points came to my mind:
usage of thread safe functions everywhere, especially strerror_r. Systematically search for all occurrences of POSIX functions that have a
_r
version (can be found out withapropos
).Imho this is the most important problem, which leads to easily reproducible crashes if two threads do something with
KDB
. I am not sure, however, if and how automatic refactoring can be helpful there.search for all global variables. If there are any, please report and let us discuss if automatic refactoring makes sense.
The text was updated successfully, but these errors were encountered: