Issue Summary

During the parallel checkpoint project, it was observed that the error handling pattern for thread creation and destruction in WiredTiger may be redundant. Specifically, when __wt_checkpoint_parallel_thread_create returns an error, the error handling in wiredtiger_open leads to __wti_connection_close, which in turn calls __wt_checkpoint_parallel_thread_destroy. This suggests that calling __wt_checkpoint_parallel_thread_destroy inside __wt_checkpoint_parallel_thread_create upon error might be unnecessary.

Context

• The sequence is as follows:

1. wiredtiger_open calls __wti_connection_workers
2. __wti_connection_workers calls __wt_checkpoint_parallel_thread_create
3. If __wt_checkpoint_parallel_thread_create returns an error, control jumps to the err label in wiredtiger_open
4. wiredtiger_open then calls __wti_connection_close, which ultimately calls __wt_checkpoint_parallel_thread_destroy

• This pattern has also been observed for chunkcache and prefetch threads.
• Example code snippet:

  wiredtiger_open
    └── __wti_connection_workers
          └── __wt_checkpoint_parallel_thread_create
    [on error]
    └── err:
          └── __wti_connection_close
                └── __wt_checkpoint_parallel_thread_destroy
  

Proposed Solution

• Review the error handling pattern for thread creation and destruction functions.
• Clarify whether it is necessary to call _wt_checkpoint_parallel_thread_destroy inside _wt_checkpoint_parallel_thread_create on error, given that the destruction will occur during connection close.
• Apply similar review to chunkcache and prefetch thread handling.

Original Slack thread
This ticket was generated by AI from a Slack thread.