Thread.destroy() Thread.stop() Thread.suspend()
so much potential for corrupted state.
In general, what you really want is for the API call to be nonblocking so you’re not forced to burn a thread.
I don’t see why glibc would have to do that inside a call to getaddrinfo. can’t it do that once at library initialization? If it has to react to changes to that file while a process is running, couldn’t it have a separate thread for polling that file for changes, or use inotify for a separate thread to be called when it changes? Swapping in the new config atomically might be problematic, but I would think that is solvable.
Even ignoring the issue mentioned it seems wasteful to open, parse, and close that file repeatedly.
“The GNU C Library is designed to be a backwards compatible, portable, and high performance ISO C library. It aims to follow all relevant standards including ISO C11, POSIX.1-2008, and IEEE 754-2008.”
⇒ I don’t think they make that argument.
If it were a library dedicated to DNS, sure, but glibc is used by nearly every process in the system, including many which will never call getaddrinfo.
It could read and parse the file the first time a thread gets created, too.
A cheaper alternative is to check the modification time of the config file, and only reparse it in pthread_cancel when that changes. That doesn’t 10% fix the problem in theory, but would do it in practice.
C libraries are not black magic. Nor are they holy code. We needn't fear them. It's the simplest part of the software stack.
When someone kills off the curl context surely you simply set a suicide flag on the thread and wake it up so it can be joined.
it makes cleanup logic convoluted when you can’t easily pthread_cleanup_push, forcing you to either block on the join or signal cancellation and detach