Should Linux distros have Tcl threads enabled?
graeme....@gmail.com
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.
ZB
> 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?
You aren't; AFAIK the recommendation of the devs was to _not_ use threads.
But perhaps those Mandriva-guys know TCL better than TCT? ;]
--
ZB
Evil Son
> Dnia 07.09.2008 graeme.piete...@gmail.com <graeme.piete...@gmail.com> napisa³/a:
>
> > 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?
>
> You aren't; AFAIK the recommendation of the devs was to _not_ use threads.
> But perhaps those Mandriva-guys know TCL better than TCT? ;]
> --
> ZB
I must have been asleep - thinking thread-enabled was the default. Or
is thread-default only with Activestate?
Cheers
Evil Son
ZB
> is thread-default only with Activestate?
Not sure. But anybody interested can find more information f.e. at:
http://www.nabble.com/tcl-threads-f4023.html
Maybe that threads-related problems were under BSD's - can't recall now.
--
ZB
Donal K. Fellows
> I recently reported the incompatibility between Tcl with threads
> enabled and the fork command in expect as a bug to my Linux distro.
The issue stems from the fact that the fork() syscall (when not
shortly followed by one of the execve() family) doesn't work at all
well with the pthread library. The killer issue relates to locks as I
understand it; we think we could work around everything else.
Arguably, we should do the almost-workaround for that issue and change
the defaults. As long as everyone allocates locks using Tcl's C API
(or is otherwise well-behaved) that could even work. But Zoran
Vasiljevic is the master of threads, so check with him rather than
me. :-)
Donal.
graeme....@gmail.com
I think:
1) thread enabled is the default for 8.5
2) Mandriva has just been compiling with the defaults.
What I really want to know is whether I am wrong is suggesting they
should compile without threads enabled. They do not, AFAIK claim any
expertise on TCL, but maintainer is open to advice (actually he is
very responsive to users) - see the bug I linked to earlier.
As an aside, the problem as I see it is the notifier thread problem
which means you cannot fork a script that does not use threads. It is
not currently a problem for me personally, but it remains a trap for
the unwary.
Evil Son
You are right. From Donal Porter, for the 8.5 series:
http://groups.google.com/group/comp.lang.tcl/msg/2d07d18e657bd17f
Cheers
Evil Son
sp...@controlq.com
I concur that FreeBSD at least has problems with 8.5.x, particularly in
conjunction with Apache/Rivet and/or SQLite if the threads issues are not
explicitly dealt with. Having said this, PHP/SQLite under Apache have
similar difficulties, so this is not a Tcl specific problem.
I would prefer that threads across the board support default to 'off', but
having found the various problems, this is now the first thing I check for
in resolving unexpected problems ... Mind you, I like to follow the
latest and greatest stable versions of Tcl, SQLite, PHP etc. As for
Rivet, my enthusiasm has wained along with the interest of the developer,
unfortunately.
Rob Sciuk
---- Posted via Pronews.com - Premium Corporate Usenet News Provider ----
http://www.pronews.com offers corporate packages that have access to 100,000+ newsgroups
GPS
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
Donal K. Fellows
> 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).
It would be a complete rewrite though; it's at a somewhat different
level of abstraction.
Donal.
Larry W. Virden
>
> I must have been asleep - thinking thread-enabled was the default. Or
> is thread-default only with Activestate?
I build primarily on sparc solaris. What I see is that the tcl core
defaults to no threading, but many extensions default to building with
threading enabled.
Does that combination result in problems as well?
Fredderic
> 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?
I don't know the technical issues much, I was following it all for a
while, then got lost and gave up. ;)
Personally, I've found the thread pool facility quite handy on a number
of occasions, and would rather miss it if my distro suddenly switched
to non-threading. But from a packaging perspective;
I wonder whether, if this is a particularly bad problem, they could
simply offer both versions under appropriately modified binary names.
The usual name would then become a link to the "default" one for the
system.
eg. tclsh8.5 -> tclsh8.5-nt (non-threaded) or tclsh8.5-th (threaded)
That allows an application that's fussy about threading to use the
appropriate version, or just use whichever one is configured as the
system default. I have a few things that don't yet support 8.5, and so
have both 8.4 and 8,5 installed, and that's exactly how that is
resolved; tclsh -> tclsh-default -> tclsh8.5
--
Fredderic
Violence is a tool of the ignorant.
Debian/unstable (LC#384816) on i686 2.6.23-z2 2007 (up 67 days, 10:33)
Evil Son
>
> You are right. From Donal Porter, for the 8.5 series:http://groups.google.com/group/comp.lang.tcl/msg/2d07d18e657bd17f
>
Should have been "Donald Porter". My apologies.
(hides)
graeme....@gmail.com
> Personally, I've found the thread pool facility quite handy on a number
> of occasions, and would rather miss it if my distro suddenly switched
> to non-threading. But from a packaging perspective;
Does you distro package the thread extension? Mandriva does not, so,
my argument is that anyone using threads is going to be compiling
their own extensions anyway, so they might as well embed Tcl. I also
think it more likely that people using threads will spot that there is
a problem if Tcl is not thread enabled, than that people using Expect
or TclX will spot that there is a problem is they use fork or signals.
>
> I wonder whether, if this is a particularly bad problem, they could
> simply offer both versions under appropriately modified binary names.
I thought of that, but I doubt they will do it if they can avoid it,
and certainly not immediately.
One thing I have not established is whether any packages actually need
thread enabled Tcl. A lot just appear to need Tcl for a Tk GUI, so I
imagine they are unlikely. Tcl extensions are all OK. Many other
packages I have no idea about.
Fredderic
> On Sep 8, 8:49 pm, Fredderic <my-name-h...@excite.com> wrote:
>> Personally, I've found the thread pool facility quite handy on a
>> number of occasions, and would rather miss it if my distro suddenly
>> switched to non-threading. But from a packaging perspective;
> Does you distro package the thread extension? Mandriva does not,
Ahhh..... Yes, mine does. That does make it just a smidgen less
useful.
>> I wonder whether, if this is a particularly bad problem, they could
>> simply offer both versions under appropriately modified binary
>> names.
> I thought of that, but I doubt they will do it if they can avoid it,
> and certainly not immediately.
Sounds familiar... heh
Well, good luck in your quest. :)
--
Fredderic
Do you feel like the bottom has fallen out of your world?
Drink a bottle of prune juice, and feel like the world
is falling out of your bottom.
-- unknown
Debian/unstable (LC#384816) on i686 2.6.23-z2 2007 (up 67 days, 15:29)
graeme....@gmail.com
> 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
I have added a summary of what I found to the bug above by going
through every Mandriva package that depends directly on Tcl, and found
that hardly anyone seems to use threads - only websh explicitly
mentions thread-safety as a feature, and no other project website
mentions it.
Personally I would perfer to have better IPC (say support for unix
sockets, or, even better, cross platform high level IPC that uses
whatever is best on the current platform) and some process mangement
in the core (fork, signals, perhaps more high level stuff to make life
easy - Iike the wya stuff like open works).
Don Porter
> Does you distro package the thread extension? Mandriva does not, so,
> my argument is that anyone using threads is going to be compiling
> their own extensions anyway, so they might as well embed Tcl.
Extensions do not require a recompile to [load] into both thread-enabled
and thread-disabled Tcl interps.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Uwe Klein
> graeme....@gmail.com wrote:
>
>> Does you distro package the thread extension? Mandriva does not, so,
>> my argument is that anyone using threads is going to be compiling
>> their own extensions anyway, so they might as well embed Tcl.
>
>
> Extensions do not require a recompile to [load] into both thread-enabled
> and thread-disabled Tcl interps.
>
uwe