#1792 Centralized the use of pthread_create and thread_setname in the create_thread_with_name function that uses thread_wrapper for compatibility across platforms and with Linux GLIBC<2.12

[fabiodepin]

• Adjusted the thread_setname function for compatibility across platforms and with Linux GLIBC<2.12;
• Centralized the use of pthread_create and thread_setname in the create_thread_with_name function that uses thread_wrapper for compatibility;

[dormando]

Thanks! There was another similar PR in the queue, not sure if you saw it.

I'm a little concerned about having to support systems older than 2010 though.

[fabiodepin]

I hadn't seen PR #952.

I have now added in this second commit the part that matters regarding FreeBSD compatibility made by @devnexen, along with the changes I proposed.

[devnexen]

does it work as expected on macOS ?

[fabiodepin]

Yes.
On MACOS, the function pthread_setname_np(const char*) sets the internal name of the calling thread to the string value specified by the name argument.
Type is done with the prctl.

Now, if the rest of the source compiled under MACOS, that's another story.

[devnexen]

Yes. On MACOS, the function pthread_setname_np(const char*) sets the internal name of the calling thread

Sure https://github.com/apple/darwin-libpthread/blob/main/src/pthread.c#L1140 but what I meant is Linux/FreeBSD allows to specify a specific thread rather than the calling one.

Now, if the rest of the source compiled under MACOS, that's another story.

🙂

[dormando]

It should build on recent MacOS: if it doesn't please report a bug.

[fabiodepin]

Sure https://github.com/apple/darwin-libpthread/blob/main/src/pthread.c#L1140 but what I meant is Linux/FreeBSD allows to specify a specific thread rather than the calling one.

Yes, but as long as you have GLIBC >= 2.12. Por isso o tratamento acima usando prctl ou pthread_setname_np on Linux.

[devnexen]

fair point even tough glibc 2.12 is already fairly old.

[dormando]

I'm a little scared to ask but; what exactly are you doing that requires a glibc from before 2010, but also a modern build of memcached?

I've been wanting to move the codebase to C11 (unions, initializers, atomics, etc) but things like this worry me.

[dormando]

I'm a little scared to ask but; what exactly are you doing that requires a glibc from before 2010, but also a modern build of memcached?

I've been wanting to move the codebase to C11 (unions, initializers, atomics, etc) but things like this worry me.

@fabiodepin can you speak to this? I'm hesitant to open the gate for supporting something so old, but I'm open to hearing about why this is necessary.

I just recently acquired a cheap mac mini so I can validate this change once I've set that up.

[fabiodepin]

In my case it was needed for use on older Debian servers, which cannot be upgraded to newer versions due to other software running on the server.
But I already have a second glibc that I can use with 'rpath', and other people who need it can use it like that, with a second glibc.

I can't say if more people need to use it or are using it on older systems. But for these cases, it is possible to install a second glibc on the system and use it separately with 'rpath'.

I support the change to C11, I even have some optimization suggestions that I have in notes to do at another time.

• These changes proposed in this PR should not generate impact and should even facilitate this part related to the use of the setname, as it centralizes its use in a place that can be validated more easily.