"Gustavo Carneiro" <[EMAIL PROTECTED]> writes: > On 9/4/06, Nick Maclaren <[EMAIL PROTECTED]> wrote: >> "Gustavo Carneiro" <[EMAIL PROTECTED]> wrote: >> > I am now thinking of something along these lines: >> > typedef void (*PyPendingCallNotify)(void *user_data); >> > PyAPI_FUNC(void) Py_AddPendingCallNotify(PyPendingCallNotify callback, >> > void *user_data); >> > PyAPI_FUNC(void) Py_RemovePendingCallNotify(PyPendingCallNotify >> > callback, void *user_data); >> >> Why would that help? The problems are semantic, not syntactic. >> >> Anthony Baxter isn't exaggerating the problem, despite what you may >> think from his posting. > > You guys are tough customers to please.
Yes. > I am just trying to solve a problem here, not create a new one; you > have to believe me. We believe you, but you are stirring the ashes of old problems. > 1. In PyGTK we have a gobject.MainLoop.run() method, which blocks > essentially forever in a poll() system call, and only wakes if/when it > has to process timeout or IO event; > 2. When we only have one thread, we can guarantee that e.g. > SIGINT will always be caught by the thread running the > g_main_loop_run(), so we know poll() will be interrupted and a EINTR > will be generated, giving us control temporarily back to check for > python signals; > 3. When we have multiple thread, we cannot make this assumption, > so instead we install a timeout to periodically check for signals. > > We want to get rid of timeouts. Now my idea: add a Python API to say: > "dear Python, please call me when you start having pending calls, > even if from a signal handler context, ok?" This seems a reasonable proposal. But it's totally a Python 2.6 thing, so how about taking a deep breath, working on a patch and submitting it when it's ready? Having to wake a process up a few times a second is ugly and annoying, sure, but it is not a release delaying problem. Cheers, mwh -- It is never worth a first class man's time to express a majority opinion. By definition, there are plenty of others to do that. -- G. H. Hardy _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com