getThreadId vs. pthread_self

[pirofti]

Hi,

On POSIX systems pthread_self() should be used to get the thread ID. This is portable and does not require the hacks currently used inside posixHandler::getThreadId(). To that end, I propose the first attached patch. Note that this is incomplete beacuse

• the constants VMIME_HAVE_GETTID, VMIME_HAVE_SYSCALL, VMIME_HAVE_SYSCALL_GETTID have not been removed from the cmake scripts

• the getThreadID() unsigned int return type should be changed to uint64_t in order to avoid duplicate IDs through casting. This requires an API change not only in platforms, but also in OpenSSLInitializer::id() which is the only consumer of thread ids that returns unsigned longs instead of unsigned ints (another possible defect). I have not put the effort into this because I do not know if this approach will be accepted.

If you find pthread_self too bold of a move, I am also attaching a second diff that permits vmime to build on OpenBSD continuing the current hackish approach.

Paul

[vincent-richard]

Hello!

Thank you for your suggestion. However, pthread_self() returns a pthread_t type, which can/should not be casted to an integer (unsigned long int). The documentation says (in pthread_equal()):

The pthread_equal() function is necessary because thread IDs should
be considered opaque: there is no portable way for applications to
directly compare two pthread_t values.

So, yes, using pthread_self() is portable, but not casting its value to an integer (it is not even required to be castable).

[vincent-richard]

However, on BSD systems, it seems there exists a pthread_getthreadid_np() ("non portable") function declared in <pthread_np.h>. Could you tell me whether it exists on your system?

[pirofti]

It is not. But if you decide to go the non-portable way, then you should probably use my second patch that uses getthrid().