Re: [Python-Dev] Signals, threads, blocking C functions
At the risk of waking up a thread that was already declared dead, but perhaps this is usefull. So, what happens is pythons signal handler sets a flag and registrers a callback. Then the main thread should check the flag and make the callback to actually do something with the signal. However the main thread is blocked in GTK and can't check the flag. Nick Maclaren wrote: ...lots of reasons why you can't do anything reliably from within a signal handler... As far as I understand it, what could work is this: -PyGTK registrers a callback. -Pythons signal handler does not change at all. -All threads that run in the Python interpreter occasionally check the flag which the signal handler sets, like the main thread does nowadays. If it is set, the thread calls PyGTKs callback. It does not do anything else with the signal. -PyGTKs callback wakes up the main thread, which actually handles the signal just like it does now. PyGTKs callback could be called from any thread, but it would be called in a normal context, not in a signal handler. As the signal handler does not change, the risk of breaking anything or causing chaos is as large/small as it is under the current scheme. However, PyGTKs problem does get solved, as long as there is _a_ thread that returns to the interpreter within some timeframe. It seems plausible that this will happen. ___ 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
Re: [Python-Dev] Signals, threads, blocking C functions
On Sat, 09 Sep 2006 12:59:23 +0200, Gustavo Carneiro <[EMAIL PROTECTED]> wrote: > On 9/9/06, Jan Kanis <[EMAIL PROTECTED]> wrote: >> However, PyGTKs problem does get >> solved, as long as there is _a_ thread that returns to the interpreter >> within some timeframe. It seems plausible that this will happen. > > No, it is not plausible at all. For instance, the GnomeVFS library > usually has a pool of thread, not doing anything, waiting for some VFS > task. It is likely that a signal will be delivered to one of these > threads, which know nothing about Python, and sit idle most of the > time. > > Regards. Well, perhaps it isn't plausible in all cases. However, it is dependant on the libraries you're using and debuggable, which broken signal handlers apparently aren't. The approach would work if you don't use libraries that block threads, and if the libraries that do, co-operate with the interpreter. Open source libraries can be made to co-operate, and if you don't have the source and a library doesn't work correctly, all bets are off anyway. But having the signal handler itself write to a pipe seems to be a cleaner solution, if it can work reliable enough for some value of 'reliable'. Jan ___ 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
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
On Thu, 06 Jul 2006 18:28:12 +0200, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > Here's the reason I think this keeps coming up, and why Guido's "just > use a class" argument doesn't really address the actual problem that's > taking place. I agree this argument is not generally applicable in every case, but why not in this specific situation? > In short: in *theory*, a rebinding operator or "nonlocal" declaration is > unnecessary. In *practice*, having one seems quite useful every time > you wander down the path that leads to having to rewrite your code just > because the language won't let you do that one tiny thing - I think this argument is a too general one. To me it is too close to "let's add every possible feature we can find, because it might be usefull to someone" :) One of the things I like about python is that it doesn't do this, and therefore the manual stays relatively small and I don't have to remember all kinds of rarely used features to make best use of the language. (I assume this is not a point of debate. repeating: Python is not Lisp ;-) ) Most of the arguments I've seen on the list are about 'how can we implement this', I'd like to see more arguments on whether this should be implemented at all. I was hoping someone would come up with a good example, so does anyone have one?? > - or so it feels like to the person who's experiencing it. Have you ever been that person, or come across such a situation? O, and I don't think the inc() example is a good one. In this incrementer the function call is all about the side effects, it's even in the name 'increment'. Incrementing is useless unless you increment /something/, so this should be better implemented as a class. ___ 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
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
On Fri, 07 Jul 2006 01:25:19 +0200, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > >>> - or so it feels like to the person who's experiencing it. >> >> Have you ever been that person, or come across such a situation? > > Many times. The hard thing about trying to provide use cases for this > is that of course you can always find another way to write it. It's > just that sometimes the nested function is a perfect solution at point > in time A, and then at point in time B, a change in the program requires > that the nested function mutate a bit of state, resulting in either a > rewrite to do it the "right" way, or hacking mutable objects. Well, not an actual example, but close enough. Leaving the rest to Guido then. ___ 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
