1

I think locking_callback is enough to lock/unlock shared data structure of OpenSSL when used in multithread environment. So why need id_callback? That is, when OpenSSL need to call it?

jww
  • 97,681
  • 90
  • 411
  • 885
Array
  • 11
  • 2

2 Answers2

0

I think locking_callback is enough to lock/unlock shared data structure of OpenSSL when used in multithread environment, so why need id_callback? that is, when OpenSSL need to call it?

OpenSSL has on the order of 40 locks. You can grep for CRYPTO_NUM_LOCKS. You can grep for CRYPTO_LOCK_ to get an idea of the components that are protected, like CRYPTO_LOCK_UI, CRYPTO_LOCK_X509_STORE, CRYPTO_LOCK_RAND, and CRYPTO_LOCK_ENGINE.

Implicit threads identifiers, like using the stack address of the thread's stack, are not unique because they can be reused. For example, from pthread_self(3) man pages:

Thread identifiers should be considered opaque: any attempt to use a thread ID other than in pthreads calls is nonportable and can lead to unspecified results.

Thread IDs are only guaranteed to be unique within a process. A thread ID may be reused after a terminated thread has been joined, or a detached thread has terminated. ...

So its difficult for OpenSSL to know how to get a unique identifier for a thread; and difficult to properly log and debug some multithreads problems without a unique identifier for each unique thread. Because of the subtleties of the problem, OpenSSL just pushes it back to the programmer to provide the unique id.

When using pthreads, it takes a little jiggering to get right. For example, with pthreads, you should provide a unique per-thread counter. See How to assign unique ids to threads in a pthread wrapper? and Retrieve pthread_create's arg from outside the thread?

Here are some related questions on Stack Overflow:

Community
  • 1
  • 1
jww
  • 97,681
  • 90
  • 411
  • 885
  • Thanks for your answer. "and difficult to properly log and debug some multithreads problems without a unique identifier for each unique thread", so could I say this identifier is just for log/debug purpose, and it's not necessary for lock/unlock? – Array May 11 '15 at 07:26
  • @Array - OpenSSL does not have a general purpose way of getting a unique id from a thread id. One size does not fit all. You have to provide it. – jww May 11 '15 at 07:45
  • Yes, I see. I have to provide the id to use OpenSSL in multithread environment. What I want to know is if this id is necessary for lock/unlock mechanism except for debug/log? – Array May 11 '15 at 08:33
0

In OpenSSL there's one error queue for each thread, so the thread id is necessary to locate it's error queue into which error code is put, I think this is one of the purpose of id_callback.

Array
  • 11
  • 2