On 9/2/06, Nick Maclaren <nmm1 at cus.cam.ac.uk> wrote: > > According to [1], all python needs to do to avoid this problem is > > block all signals in all but the main thread; then we can guarantee > > signal handlers are always called from the main thread, and pygtk > > doesn't need a timeout. > > 1) That page is password protected, so I can't see what it says, and > am disinclined to register myself to yet another such site. Oh, sorry, here's the comment: (coment by Arjan van de Ven): | afaik the kernel only sends signals to threads that don't have them blocked. | If python doesn't want anyone but the main thread to get signals, it should just | block signals on all but the main thread and then by nature, all signals will go | to the main thread.... > 2) No way, Jose, anyway. The POSIX signal handling model was broken > beyond redemption, even before threading was added, and the combination > is evil almost beyond belief. That procedure is good practice, yes, > but that is NOT all that you have to do - it may be all that you CAN > do, but that is not the same. > > Nope. Sorry, but you can't solve a broken design by adding interfaces. Well, Python has a broken design too; it postpones tasks and expects to magically regain control in order to finish the job. That often doesn't happen! > > > But I would really prefer the first alternative, as it could be > > fixed within python 2.5; no need to wait for 2.6. > > It clearly should be done, assuming that Python's model is that it > doesn't want to get involved with subthread signalling (and I really, > but REALLY, recommend not doing so). The best that can be done is to > say that all signal handling is the business of the main thread and > that, when the system bypasses that, all bets are off. Python is halfway there; it assumes signals are to be handled in the main thread. However, it _catches_ them in any thread, sets a flag, and just waits for the next opportunity when it runs again in the main thread. It is precisely this "split handling" of signals that is failing now. Anyway, attached a patch that should fix the problem in posix threads systems, in case anyone wants to review. Cheers. -------------- next part -------------- A non-text attachment was scrubbed... Name: pythreads.diff Type: text/x-patch Size: 1030 bytes Desc: not available Url : http://mail.python.org/pipermail/python-dev/attachments/20060902/b91250df/attachment.bin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4