Uploaded image for project: 'C Driver'
  1. C Driver
  2. CDRIVER-2863

Consider API to allow program to optionally provide custom threading intrinsics



    • Type: New Feature
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Won't Fix
    • Affects Version/s: 1.13.0
    • Fix Version/s: None
    • Component/s: libbson
    • Labels:
    • Backwards Compatibility:
      Fully Compatible


      src/common/common-thread-private.h includes a bunch of macros that abstract between using the windows or pthreads threading primitives. However, in some environments you need finer control over this.

      For example, we have our own code that tracks all of the threads that are running and enables some profiling. We also have our own mutex/cvar wrappers that also have extended functionality available. However now our accounting for the running threads is inaccurate because _mongoc_topology_run_background() is creating pthreads behind our back.

      OpenSSL is a good citizen in this regard – it provides APIs like CRYPTO_set_dynlock_*_callback() which let us register callbacks for creating/locking/unlocking/destroying mutex objects, so we can make it use the same extended primitives that all of our other code does.

      mongoc is a more complicated case since its internal threading needs go beyond simple mutexes, but it would be really helpful if the common-thread-private.h stuff was better abstracted behind a callback interface (like a struct filled with function pointers, with objects like mutexes being only visible as anonymous struct pointers) and an API was provided so that before the library was used we could provide our own implementation. Of course, if our own wasn't provided it would just use the same win32/pthread implementations.




            • Votes:
              0 Vote for this issue
              3 Start watching this issue


              • Created: