Re: Should Linux distros have Tcl threads enabled?



graeme.pietersz@xxxxxxxxx wrote:
I recently reported the incompatibility between Tcl with threads
enabled and the fork command in expect as a bug to my Linux distro.

The obvious solution is to compile without threads enabled, but I was
asked what the disadvantages would be.

Given that they do not have the threads extension in the repos, and I
do not think there is much out there that depends on Tcl being
threaded, I am inclined to think non-threads-enabled should be the
default.

Why am I wrong?

The bug report and comments so far are here:

https://qa.mandriva.com/show_bug.cgi?id=42596

Any other Mandriva users who have a view on this might want to comment
there.


There are several Tcl extensions that don't work well with threads.

1. Expect uses fork() and Tcl's notifier doesn't work with that, or the
pthread library. The pthread fork behavior is less than ideal. Donal
covered this issue well.

2. TclX's signal handling mechanism is very prone to deadlock when used
with --enable-threads, because it locks a mutex via the Tcl Async API
from what I recall.

To quote from the manual for GNU/Linux (other implementations are
probably very similar, and POSIX doesn't require pthread_mutex_lock() to
be async-signal safe):

"The mutex functions are not async-signal safe. What this means is that
they should not be called from a signal handler. In particular, calling
pthread_mutex_lock or pthread_mutex_unlock from a signal handler may
deadlock the calling thread."

3. Tk's thread support for unix/X11 is iffy. There has been work done
on making Tk thread safe, but Tk still doesn't call XInitThreads(), and
probably won't anytime soon. It seems that the XCB library has a
superior implementation for threaded X11 interfaces anyway, so a
complete rewrite would make more sense (to me). Tk however can be used
with threaded builds, and multiple threads, but only with a single
thread using [package require Tk] as I understand it.


George
.