There has been ongoing discussion for some time about the thread safety of
OpenRTE. This note proposes a solution to that problem that has been kicked
around for the last several months, and that Jeff and I feel makes a certain
degree of sense.
We propose to make OpenRTE appear "single-threaded" to outside users. By
that we do not mean that OpenRTE may not have some internal threads in
operation. Instead, we mean that thread locking would be the responsibility
of anyone calling an OpenRTE function - as opposed to built into the OpenRTE
Most of the logic inside of OpenRTE is serial in nature and therefore
resistant to the use of threads. Accordingly, we find ourselves putting
giant thread locks around virtually every function in the code base. This
wastes our time, complicates the code (we all keep forgetting to unlock when
exiting due to errors), and basically eliminates any benefits from threading
Those few places where threading is possible are actually involved in
OpenRTE-internal operations. For example, we now use a thread to accept
out-of-band communication socket connections. These operations, however, are
transparent to the user level (i.e., any code that calls OpenRTE).
It seems, therefore, that the simplest solution is to place the
responsibility for thread locking onto the calling programs. Unthreaded
programs need do nothing. Programs utilizing threads, however, would need to
thread lock prior to calling OpenRTE functions.
Any comments on this idea? If not, or if there is general consensus on this
approach, then we would gradually remove the current thread locks as code is
revised - this isn't a high priority issue requiring an immediate scrub of