Re: [Python-Dev] Signals, threads, blocking C functions
Jan Kanis 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. I don't see that this makes the situation much better, as it just shifts the need for polling to another thread. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/greg.ewing%40canterbury.ac.nz ___ 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] Py_BuildValue and decref
Barry Warsaw wrote: > I just want to point out that the C API documentation is pretty > silent about the refcounting side-effects in error conditions (and > often in success conditions too) of most Python functions. For > example, what is the refcounting side-effects of PyDict_SetItem() on > val? What about if that function fails? Has val been incref'd or > not? What about the side-effects on any value the new one replaces, > both in success and failure? The usual principle is that the refcounting behaviour is (or should be) independent of whether the function succeeded or failed. In the absence of any statement to the contrary in the docs, you should be able to assume that. The words used to describe the refcount behaviour of some functions can be rather confusing, but it always boils down to one of two cases: either the function "borrows" a reference (and does its own incref if needed, the caller doesn't need to care) or it "steals" a reference (so the caller is always responsible for doing an incref if needed before calling). What that rather convoluted comment about PyTuple_SetItem is trying to say is just that it *always* steals a reference, regardless of whether it succeeds or fails. I expect the same is true of Py_BuildValue. -- Greg ___ 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] Signals, threads, blocking C functions
On 9/9/06, Nick Maclaren <[EMAIL PROTECTED]> wrote: > I can't honestly promise to put any time into this in the forseeable > future, but will try (sometime). If anyone wants to tackle this, > please ask me for comments/help/etc. It took me a while to realize just what was wrong with my proposal, but I did, and it led me to a new proposal. I'd appreciate if you could point out any holes in it. First though, for the benefit of those reading, I'll try to explain the (multiple!) reasons why mine fails. First, sig_atomic_t essentially promises that the compiler will behave atomically and the CPU it's ran on will behave locally atomic. It does not claim to make writes visible to other CPUs in an atomic way, and thus you could have different bytes show up at different times. The x86 architecture uses a very simple scheme and won't do this (unless the compiler itself does), but other architectures will. Second, the start of a write call may be delayed a very long time. This means that a fd may not be written to for hours until after the signal started. We can't release any fd's used for such a purpose, or else risk random writing to them if they get reused later.. Third, it doesn't resolve the existing problems. If I'm going to fix signals I should fix ALL of signals. :) Now on to my new proposal. I do still use write(). If you can't accept that I think we should rip signals out entirely, just let them kill the process. Not a reliable feature of any OS. We create a single pipe and use it for all signals. We never release it, instead letting the OS do it when the process gets cleaned up. We write the signal number to it as a byte (assuming there's at most 256 unique signals). This much would allow a GUI's poll loop to wake up when there is a signal, and give control back to the python main loop, which could then read off the signals and queue up their handler functions. The only problem is when there is no GUI poll loop. We don't want python to have to poll the fd, we'd rather it just check a variable. Is it possible to set/clear a flag in a sufficiently portable (reentrant-safe, non-blocking, thread-safe) fashion? -- Adam Olsen, aka Rhamphoryncus ___ 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
[Python-Dev] 2.5c2
PEP 356 http://www.python.org/dev/peps/pep-0356/ has 2.5c2 scheduled for Sept 12. I checked in a fix for the last blocking 2.5 issue (revert sgml infinite loop bug). There are no blocking issues that I know of (the PEP is up to date). I expect Anthony will call for a freeze real soon now. It would be awesome if there were no more changes from now until for 2.5 final! (Changing the trunk or 2.4 branches are fine, updating doc for 2.5 is also fine). I will be running valgrind over 2.5, but don't expect anything to show up since the last run was pretty recent. Coverity has no outstanding issues and Klocwork results are pretty clean. It's not clear if the remaining warnings from Klocwork are real issues or not. Keep doing a bunch of testing so we don't have any surprises in 2.5. n PS Scary as it sounds, I hope to have an HP-UX buildbot up and running real soon now. After 2.5 is out, I will fix the issues with the cygwin bot (ie, upgrade cygwin) and get the HP-UX bot running. ___ 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
