Threading and Practical Applications

70 ERR_print_errors_fp will produce an error listing and write it to a standard C runtime FILE object. The error listings are produced by iterating through each error report in the error queue and removing them as it goes. For each error report, ERR_get_error_line_data and ERR_error_string are used to obtain the information necessary to produce the listing: void ERR_print_errorsBIO bp; bp The BIO that the error listing should be written to. void ERR_print_errors_fpFILE fp; fp The FILE object that the error listing should be written to.

4.2.3 Threading and Practical Applications

A common concern of developers is the handling of errors produced by a library when using threaded code, and rightly so. With a few exceptions that can be easily avoided, OpenSSLs error handling is completely thread-safe. Each thread is assigned its own error queue, which is one of the reasons why the id_function callback that we described earlier in the chapter must return a different identifier for each thread. Each error queue will contain only errors that were caused by that thread. This is convenient for threaded applications because the programmer doesnt need to do anything special to handle errors correctly. By creating a separate error queue for each thread, it would seem that all the bases are covered for error handling, but thats not entirely true. OpenSSL does not use thread-local storage for the error queues, and so there is no way for each queue to be automatically destroyed when a thread terminates. Thread-local storage is a great feature to have in a multithreaded environment, but unfortunately, it is not supported on all platforms. The bottom line is that the application is responsible for destroying a threads error queue when a thread terminates because OpenSSL has no way of knowing on its own when a thread has terminated. OpenSSL provides a function to destroy a threads error queue called ERR_remove_state . It should be called by a thread just before it terminates, or it may be called by another thread within the process after the thread has terminated. The function requires a single argument that is the identifier of the thread as it would be returned by the id_function callback that we described earlier in the chapter. Until now, we have overlooked the implications of loading the strings for error processing. These strings do take up memory, and it isnt always appropriate to load them. It should be mentioned that all of the error handling routines work properly without the strings loaded. The translated error messages will merely have internal OpenSSL codes inserted instead of the more meaningful strings. If we do choose to load the error strings, we should also be sure to free them when theyre no longer needed by calling ERR_free_strings . For most applications, this should happen after the program is done making calls into the OpenSSL library.

4.3 Abstract InputOutput