[Python-Dev] Suggested API change to PyOS_InputHook
I have a problem with the PyOS_InputHook() API as implemented by
Modules/readline.c: there is no way to communicate any interruption seen
while waiting at the keyboard back to the process actually reading the
line.
I have solved this in my own application by creating a new module which
reimplements the call_readline function and which has the following patch
to readline_until_enter_or_signal():
FD_SET(fileno(rl_instream), &selectset);
/* select resets selectset if no input was available */
has_input = select(fileno(rl_instream) + 1, &selectset,
NULL, NULL, &timeout);
- if(PyOS_InputHook) PyOS_InputHook();
+if (call_readline_InputHook &&
+call_readline_InputHook(fileno(rl_instream)))
+{
+has_input = -1;
+PyErr_SetInterrupt();
+break;
+}
}
if(has_input > 0) {
rl_callback_read_char();
}
- else if (errno == EINTR) {
+else if (errno == EINTR || has_input < 0) {
int s;
#ifdef WITH_THREAD
PyEval_RestoreThread(_PyOS_ReadlineTState);
(I'm sorry, this isn't a proper patch, but hopefully if you've read this
far you can figure out where it applies.)
Here I've replaced PyOS_InputHook with effective type signature None->None
with my own call_readline_InputHook which takes a file descriptor and
returns a boolean, returning True iff an interrupt occurred. The file
descriptor argument is a triviality, but the boolean return code is
clearly crucial.
Now, I don't know how this change might fit into mainstream Python, but I
think there is a case for making this change. If the incompatibility was
acceptable it would be better to change the signature of PyOS_InputHook (I
declared my own variable call_readline_InputHook just to avoid accidents).
I've checked the current svn trunk, and this change remains applicable.
Please CC me in any replies: I am quite literally unable to cope with the
volume of traffic that a subscription to python-dev will give me.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C API for gc.enable() and gc.disable()
Martin v. Löwis v.loewis.de> writes: > Currently, only youngest collections are triggered by allocation > rate; middle and old are triggered by frequency of youngest collection. > So would you now specify that the youngest collection should occur > if-and-only-if a new arena is allocated? Or discount arenas returned > from arenas allocated? The latter sounds reasonable. IIRC an arena is 256KB, which is less than an entry level L2 cache. Therefore waiting for an arena to be filled shouldn't deteriorate cache locality a lot. To avoid situations where the GC is never called we could combine that with an allocation counter, but with a much higher threshold than currently. > Or apply this to triggering other generation > collections but youngest? How would that help the quadratic behavior > (which really needs to apply a factor somewhere)? It would not help the quadratic behaviour - and is orthogonal to your proposal - , but at least avoid calling the GC too often when lots of small objects are allocated (as opposed to lots of large objects). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Suggested API change to PyOS_InputHook
On Mon, Jun 23, 2008, Michael Abbott wrote: > > Please CC me in any replies: I am quite literally unable to cope with the > volume of traffic that a subscription to python-dev will give me. Then don't bother posting code to the list. Please post a patch; up to you whether you send a notice to python-dev. And expect that you'll probably miss at least some replies. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "as long as we like the same operating system, things are cool." --piranha ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Suggested API change to PyOS_InputHook
On Mon, 23 Jun 2008, Aahz wrote: > Then don't bother posting code to the list. Please post a patch; up to > you whether you send a notice to python-dev. Very well. Issue 3180 created. I hope I'm doing it right... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Suggested API change to PyOS_InputHook
Michael Abbott wrote: Please CC me in any replies: I am quite literally unable to cope with the volume of traffic that a subscription to python-dev will give me. You can read python-dev (and 1000s of other mail lists, with a newsreader, like I do, for the same reason, via the free list to news gateway news.gmane.com tjr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C API for gc.enable() and gc.disable()
> It would not help the quadratic behaviour - and is orthogonal to your > proposal - > , but at least avoid calling the GC too often when lots of small objects are > allocated (as opposed to lots of large objects). I'd like to see in an experiment whether this is really true. Current GC only takes into account container objects, which, most significantly, ignores string objects (of which most applications create plenty). If you make actual memory consumption a trigger, the string objects would count towards triggering GC. That may or may not be the better approach, anyway - but it's not certain (for me) that such a scheme would cause GC to be triggered less often, in a typical application. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
