Re: [Python-Dev] Signals, threads, blocking C functions
Martin v. Löwis [EMAIL PROTECTED] writes: Michael Hudson schrieb: According to [1], all python needs to do to avoid this problem is block all signals in all but the main thread; Argh, no: then people who call system() from non-main threads end up running subprocesses with all signals masked, which breaks other things in very mysterious ways. Been there... Python should register a pthread_atfork handler then, which clears the signal mask. Would that not work? Not for system() at least: http://mail.python.org/pipermail/python-dev/2003-December/041303.html Cheers, mwh -- ROOSTA: Ever since you arrived on this planet last night you've been going round telling people that you're Zaphod Beeblebrox, but that they're not to tell anyone else. -- The Hitch-Hikers Guide to the Galaxy, Episode 7 ___ 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
[Python-Dev] RELEASED Python 2.5 (release candidate 2)
On behalf of the Python development team and the Python community, I'm happy to announce the second RELEASE CANDIDATE of Python 2.5. After the first release candidate a number of new bugfixes have been applied to the Python 2.5 code. In the interests of making 2.5 the best release possible, we've decided to put out a second (and hopefully last) release candidate. We plan for a 2.5 final in a week's time. This is not yet the final release - it is not suitable for production use. It is being released to solicit feedback and hopefully expose bugs, as well as allowing you to determine how changes in 2.5 might impact you. As a release candidate, this is one of your last chances to test the new code in 2.5 before the final release. *Please* try this release out and let us know about any problems you find. In particular, note that changes to improve Python's support of 64 bit systems might require authors of C extensions to change their code. More information (as well as source distributions and Windows and Universal Mac OSX installers) are available from the 2.5 website: http://www.python.org/2.5/ As of this release, Python 2.5 is now in *feature freeze*. Unless absolutely necessary, no functionality changes will be made between now and the final release of Python 2.5. The new features in Python 2.5 are described in Andrew Kuchling's What's New In Python 2.5. It's available from the 2.5 web page. Amongst the language features added include conditional expressions, the with statement, the merge of try/except and try/finally into try/except/finally, enhancements to generators to produce a coroutine kind of functionality, and a brand new AST-based compiler implementation. New modules added include hashlib, ElementTree, sqlite3, wsgiref, uuid and ctypes. In addition, a new profiling module cProfile was added. Enjoy this new release, Anthony Anthony Baxter [EMAIL PROTECTED] Python Release Manager (on behalf of the entire python-dev team) ___ 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 9/12/06, Adam Olsen [EMAIL PROTECTED] wrote:
On 9/12/06, Gustavo Carneiro [EMAIL PROTECTED] wrote:
On 9/12/06, Adam Olsen [EMAIL PROTECTED] wrote:
My previous mention of using a *single* flag may survive corruption
simply because we can tolerate false positives. Signal handlers would
write 0x, the poll loop would check if *any* bit is set. If
so, write 0x0, read off the fd, then loop around and check it again.
If the start of the read() acts as a write-barrier it SHOULD guarantee
we don't miss any positive writes.
Why write 0x? Why can't the variable be of a volatile
char type? Assuming sizeof(char) == 1, please don't tell me
architecture XPTO will write the value 4 bits at a time! :P
Nope. It'll write 32 bits, then break that up into 8 bits :)
Although, at the moment I can't fathom what harm that would cause...
Hmm... it means that to write those 8 bits the processor / compiler
may need to 1. read 32 bits from memory to a register, 2. modify 8
bits of the register, 3. write back those 32 bits. Shouldn't affect
our case, but maybe it's better to use sig_atomic_t in any case.
For the record, all volatile does is prevent compiler reordering
across sequence points.
It makes the compiler aware the value may change any time, outside
the current context/function, so it doesn't assume a constant value
and always re-reads it from memory instead of assuming a value from a
register is correct.
static volatile char signal_flag;
static int signal_pipe_r, signal_pipe_w;
PyErr_CheckSignals()
{
if (signal_flag) {
char signum;
signal_flag = 0;
while (read(signal_pipe_r, signum, 1) == 1)
process_signal(signum);
}
}
I'd prefer this to be a while (signal_flag) instead, although it
should technically work either way.
I guess we can use while instead of if.
static void
signal_handler(int signum)
{
char signum_c = signum;
signal_flag = 1;
write(signal_pipe_w, signum_c, 1);
}
This is wrong. PyErr_CheckSignals could check and clear signal_flag
before you reach the write() call. signal_flag = 1 should come
after.
Yes, good catch.
I don't understand the memory barrier concern in your other email.
I know little on the subject, but from what I could find out memory
barriers are used to avoid reordering of multiple read and write
operations. However, in this case we have a single value at stake,
there's nothing to reorder.
Except perhaps that signal_flag = 0 could be delayed... If it is
delayed until after the while (read (...)...) loop below we could get
in trouble. I see your point now... :|
But I think that a system call has to act as memory barrier,
forcefully, because the CPU has to jump into kernelspace, a completely
different context, it _has_ to flush pending memory operations sooner
or later.
Round two:
static volatile sig_atomic_t signal_flag;
static int signal_pipe_r, signal_pipe_w;
PyErr_CheckSignals()
{
while (signal_flag) {
char signum;
signal_flag = 0;
while (read(signal_pipe_r, signum, 1) == 1)
process_signal(signum);
}
}
static void
signal_handler(int signum)
{
char signum_c = signum;
write(signal_pipe_w, signum_c, 1);
signal_flag = 1;
}
--
Gustavo J. A. M. Carneiro
The universe is always one step beyond logic.
___
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
[Python-Dev] Maybe we should have a C++ extension for testing...
Building Python with C and then linking in extensions written in or wrapped with C++ can present problems, at least in some situations. I don't know if it's kosher to build that way, but folks do. We're bumping into such problems at work using Solaris 10 and Python 2.4 (building matplotlib, which is largely written in C++), and it appears others have similar problems: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6395191 http://mail.python.org/pipermail/patches/2005-June/017820.html http://mail.python.org/pipermail/python-bugs-list/2005-November/030900.html I attached a comment to the third item yesterday (even though it was closed). One of our C++ gurus (that's definitely not me!) patched the Python source to include wchar.h at the top of Python.h. That seems to have solved our problems, but seems to be a symptomatic fix. I got to thinking, should we a) encourage people to compile Python with a C++ compiler if most/all of their extensions are written in C++ anyway (does that even work if one or more extensions are written in C?), or b) should the standard distribution maybe include a toy extension written in C++ whose sole purpose is to test for cross-language problems? Either/or/neither/something else? Skip ___ 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
[Python-Dev] .pyc file has different result for value 1.79769313486232e+308 than .py file
We've noticed a strange occurance on Python 2.4.3 w/ the floating point value
1.79769313486232e+308 and how it interacts w/ a .pyc. Given x.py:
def foo():
print str(1.79769313486232e+308)
print str(1.79769313486232e+308) == 1.#INF
The 1st time you run this you get the correct value, but if you reload the
module after a .pyc is created then you get different results (and the
generated byte code appears to have changed).
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32
Type help, copyright, credits or license for more information.
import x
import dis
dis.dis(x.foo)
2 0 LOAD_GLOBAL 0 (str)
3 LOAD_CONST 1 (1.#INF)
6 CALL_FUNCTION1
9 PRINT_ITEM
10 PRINT_NEWLINE
3 11 LOAD_GLOBAL 0 (str)
14 LOAD_CONST 1 (1.#INF)
17 CALL_FUNCTION1
20 LOAD_CONST 2 ('1.#INF')
23 COMPARE_OP 2 (==)
26 PRINT_ITEM
27 PRINT_NEWLINE
28 LOAD_CONST 0 (None)
31 RETURN_VALUE
reload(x)
module 'x' from 'x.pyc'
dis.dis(x.foo)
2 0 LOAD_GLOBAL 0 (str)
3 LOAD_CONST 1 (1.0)
6 CALL_FUNCTION1
9 PRINT_ITEM
10 PRINT_NEWLINE
3 11 LOAD_GLOBAL 0 (str)
14 LOAD_CONST 1 (1.0)
17 CALL_FUNCTION1
20 LOAD_CONST 2 ('1.#INF')
23 COMPARE_OP 2 (==)
26 PRINT_ITEM
27 PRINT_NEWLINE
28 LOAD_CONST 0 (None)
31 RETURN_VALUE
^Z
___
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] .pyc file has different result for value 1.79769313486232e+308 than .py file
[Dino Viehland] We've noticed a strange occurance on Python 2.4.3 w/ the floating point value 1.79769313486232e+308 and how it interacts w/ a .pyc. Given x.py: def foo(): print str(1.79769313486232e+308) print str(1.79769313486232e+308) == 1.#INF The 1st time you run this you get the correct value, but if you reload the module after a .pyc is created then you get different results (and the generated byte code appears to have changed). ... Exhaustively explained in this recent thread: http://mail.python.org/pipermail/python-list/2006-August/355986.html ___ 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] .pyc file has different result for value 1.79769313486232e+308 than .py file
Thanks for the link - it's a good explanation. FYI I've opened a bug against the VC++ team to fix their round tripping on floating point values (doesn't sound like it'll make the next release, but hopefully it'll make it someday). -Original Message- From: Tim Peters [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 13, 2006 11:39 AM To: Dino Viehland Cc: python-dev@python.org; Haibo Luo Subject: Re: [Python-Dev] .pyc file has different result for value 1.79769313486232e+308 than .py file [Dino Viehland] We've noticed a strange occurance on Python 2.4.3 w/ the floating point value 1.79769313486232e+308 and how it interacts w/ a .pyc. Given x.py: def foo(): print str(1.79769313486232e+308) print str(1.79769313486232e+308) == 1.#INF The 1st time you run this you get the correct value, but if you reload the module after a .pyc is created then you get different results (and the generated byte code appears to have changed). ... Exhaustively explained in this recent thread: http://mail.python.org/pipermail/python-list/2006-August/355986.html ___ 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] .pyc file has different result for value 1.79769313486232e+308 than .py file
[Dino Viehland]
FYI I've opened a bug against the VC++ team to fix their round tripping on
floating
point values (doesn't sound like it'll make the next release, but hopefully
it'll make it
someday).
Cool! That would be helpful to many languages implemented in C/C++
relying on the platform {float, double}-string library routines.
Note that the latest revision of the C standard (C99) specifies
strings for infinities and NaNs that conforming implementations must
accept (for example, inf). It would be nice to accept those too,
for portability; most Python platforms already do. In fact, this is
the primary reason people running on, e.g., Linux, resist upgrading to
Windows ;-)
___
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
[Python-Dev] release is done, but release25-maint branch remains near-frozen
Ok - we're looking at a final release in 7 days time. I really, really, really don't want to have to cut an rc3, so unless it's a seriously critical brown-paper-bag bug, let's hold off on the checkins. Documentation, I don't mind so much - particularly any formatting errors. -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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
