[Python-bugs-list] PRIVATE: Threads and readline (PR#120)

[guido@CNRI.Reston.VA.US]

------- Forwarded Message

Date:    Tue, 02 Nov 1999 11:57:23 +0000
From:    Alex Zbyslaw <xfb52@dial.pipex.com>
To:      guido@cnri.reston.va.us
Subject: RE: Re: [Python-bugs-list] PRIVATE: Threads and readline

>> When python is compiled with thread support and readline, ^C no longer
>> works properly (interpreter goes into an infinite loop).
>> (Tried with readline 2.0, 2.2 and 4.0).

>Thanks for your bug report.  I see that you are using FreeBSD.  Could
>it be a FreeBSD related problem?  I don't see the same thing on
>Solaris or Red Hat Linux.
>
>Also, can you describe exactly how you reproduce the problem?
>
>--Guido van Rossum (home page: http://www.python.org/~guido/)

Thanks for your mail, Guido.  Yes, I suppose it could be a FreeBSD
problem, though I was originally put on to the readline connection by
some articles in comp.lang.python which mentioned extremely similar
symptoms under Debian Linux.  What those articles did not mention was
the thread connection which I guessed for myself.  See articles titled
"Control-C on Unix meisbehaviour?" on 18th Oct 1999.  People in that
thread reported similar problems on various systems, whilst others had
no problem on apparently identical systems.  No one mentioned if they
had thread support.

Creating the problem is, for me, simple.  I compile python 1.5.2 with
thread support enabled.  (Thread and signal tests are passed by make
test and a quickie thread program works as expected).  If I go into the
interpreter
	python
and type ^C, everything goes into an infinite loop.

If I recompile python without threads, but with readline, then go into
the interpreter then press ^C I get KeyboardInterrupt as expected.

If I recompile with threads but without readline, then again, I get
KeyboardInterrupt as expected.

In all three cases, pressing ^C while a program is running gets correct
behaviour.



>From what I can determine:
	The readline module was written so that it bypassed any signal handler
installed by the readline library.  It institutes its own handler in
readline.c (onintr) which catches the interrupt and returns NULL (which
somewhere back down the line is interpreted as KeyboardInterrupt).

	However, with threads enabled (but no readline) there seems to be a
different behaviour, where the interrupt is caught by the regular signal
handler (I forget the name but its in my bug report - in
signalmodule.c).  My guess was that with threads enabled this signal
handler was doing something important.  But with readline support turned
on, this handler was not being called which caused some problem occur. 
I did try adapting the code in readline.c to call this signal handler
itself, but that didn't seem to work (though I forget what happened).

What my patch does is to forget about the local signal handler 'onintr'
and, instead, stick with whatever the "default" signal handler is. 
readline_4.0 allows you to turn off any signal handling in the readline
library itself, so the "default" handler will be whatever python
installs (in signalmodule.c).

This then "works" in that pressing ^C does not generate an infinite
loop.  But the call_readline function in readline.c does not immediately
return NULL, so you have to press RETURN before the KeyboardInterrupt is
generated.  

I never did figure out a way to both call the default signal handler and
return a NULL from call_readline -- which I believe would cause
"correct" ^C behaviour.  My C is somewhat rusty as I spend my time in
Python (by choice) and Perl (by neccessity).


I'm not sure what else I can tell you about the problem, but if there is
any more data I could provide for you, please ask.



As another bizarre data point: when I run a threaded python interpreter
on a program which does not use threads, and pipe the output to less,
less gets very confused and fails to update about half the screen,
leaving it blank.  This happens after hitting SPACE a couple of times. 
All the data is there, and if I jump less to the end of input and then
go back through the the data, I can see it all normally. Same program
and unthreaded python and less works just fine.  If you have ANY idea
why adding thread support could affect a program further down a pipe I'd
love to know.


By the way, I have no objection to making my bug report and patch
public, as long as there is some way to remove my email address from
it.  I have had only one piece of spam in the last year and I'd like to
keep it that way :-) As the good cafe owner said "Spam's orf"!  Although
it's not perfect, the patch has made threaded python usable for me. If
there are other people out there in the same boat and it helped them,
that would be great.


- -- 
Phone: 0131 468 2422
Email: xfb52@dial.pipex.com

------- End of Forwarded Message