Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Donal K. F. <don...@ma...>]

On 17/03/2010 05:27, Elchonon Edelson wrote:
> What are the problems with Expect that make threads such a non-option?

I don't know. To be honest, I don't really grok the innards of Expect
enough to be able to say off-hand. However, if you're up to looking then
the things to check for are fork() and signal handling; they're known to
be problems (due to the notifier and POSIX botches, respectively). Both
of those become nastier when there are threads about.

I ought to look at the Expect sources sometime so I can argue from
knowledge instead of (mainly) ignorance. :-)

> What options are there for a fix, or a work-around? If there were a good
> writeup of the issue, a good starting point would be to include a note
> in the Expect distribution, and possibly have Expect's ./configure issue
> a warning if you're configuring against a threaded Tcl.

Yes. If fork and signals are just in there "because it is convenient"
then it might be better off to say that people wanting them should add a
[package require TclX] too. Separation of concerns and all that.

> While I like Expect, and would very much hate to lose it, I don't think
> an extension should be able to hold Tcl hostage in the way that it
> sounds like Expect is doing. My opinion is that you should do what you
> need to with Tcl. By all means, of course, let Expect know how and why
> it's being broken, and maybe if what's being broken is important enough,
> someone will find a way to fix it. In the mean time, if they need it
> that badly, they'll still be able to make their own non-threaded build,
> just for Expect, right?

My big concern with that is that a lot of the deployed uses of Tcl are
for Expect, and they tend to be people who are not following what we're
doing here closely. Being able to say "oh, you'll need an updated
Expect" is one type of story, saying "oh, that doesn't work any more" is
a totally different one.

Donal.