Updated 2015-09-03 01:23:04 by mistachkin ▲

The purpose of this page is to catalog Tcl extensions believed to be safe for use in multi-threaded Tcl applications, along with the version numbers in which thread safety was added. This list might change as the definition of "thread-safe" evolves in the Tcl community.

It is important to note that pure Tcl libraries (such as anything in tcllib) is thread-safe. However, one should be careful when using certain libraries in tcllib that may require external libraries optionally for [speed] (such as md5). These should perhaps be checked to either not use the [external library] when built threaded, or verify that the external library is thread-safe.

Even though a library may be listed as "thread-safe" here, it is likely necessary to ensure that the library was built with -D[TCL_THREADS] (usually with ./configure --[enable-threads]).

Current versions of Tclx appear NOT to be thread-safe. In fact, the tclx readdir comand fails to return valid values whether or not tclx was compiled with the threads configuration activated.

Here is a list of thread-safe and not-safe libraries, at the bottom of the page.

http://httpd.apache.org/docs-2.0/developer/thread_safety.html

Well, let me be the first to define "thread-safe":
  thread safe code does not fail with a segfault two times,
  then once with a bus error, then run for a week followed
  by a hardware lockup.
                           -PSE

UKo: If an extension is not (known) threadsafe, is it safe to use it in only one thread?

RFox: Maybe... maybe not. Depends on why it's not thread safe.

Duoas: UKo, you'll have to do some reading on threads and processes. Tcl has a very process-like thread model and a lot of nice thread synchronization automatically at work. The problem is, an extension provides its own data core. Imagine two or three threads all calling one of an extension's routines which directly manipulates its extension data. The routine in thread one modifies variable 1, thread two modifies variable 1, thread one uses the (now potentially invalid) variable 1, thread three sticks its thumb in... etc. So, if you can absolutely guarantee that only one thread uses an extension, then yes, you can use it. However, making that guarantee might be a bit more difficult than it would seem at first blush. For example, how do you use incr Tcl in only one thread?

UKo: Thanks for your answers! My aim is at snack and I don't know for sure whether it's threadsafe or not. And there it is possible to have only one thread for all sound objects. So if I understand you, I can use snack (without knowing whether it's threadsafe or not) in a threaded tcl if I guarentee it's only used by one thread, right?

Duoas: I know nothing more about Snack than what is on its homepage and here on the Wiki... but in general sound extensions have their own threads for handling sound. In other words, there is no need to fork a thread just to handle the sound toolkit because the sound toolkit forks its own threads. However, if your application requires threads for other reasons then make sure you are using Snack in just one. Hope this helps.

DKF: Note that some extensions are actually thread-agnostic rather than thread-safe; they have no global data at all, do not return structs from any of their implementation functions, and instead store all their private information bound to each interpreter that the extension package is present in. Because interpreters are bound to their owning threads, this in turn means that the extension is automatically thread-safe, though we prefer thread-agnostic as a term as that's actually a stronger statement. (Also, thread-agnostic extensions do not call any of Tcl's explicit thread-related API, though they might call Tcl functions that have an implementation that does.)

Typically, being thread-agnostic is common for extensions that implement functionality that doesn't interact with the OS (such as TclOO). Interactions with the OS are usually trickier, though Tcl itself can often act as an isolation layer.

Category Threads