Re: [Python-Dev] Bugs in thread_nt.h
On Wed, Mar 9, 2011 at 8:42 PM, Martin v. Löwis mar...@v.loewis.de wrote: As for the volatile marker - I believe the code is also correct without it, since the owned field is only accessed through initialization and Interlocked operations. Furthermore, if the code weren't correct, volatile would only be half the solution since it only restricts compiler-induced reorders. Some sort of CPU fence instruction would almost certainly be needed as well. Sturla wrote: releasing the time-slice by Sleep(0) for each iteration, it will certainly fail without a volatile qualifier. In general, your compiler will reload globally-accessible memory after a function call (or after a memory store). In fact, it can be quite a job to give them enough hints that they stop doing so! This behavior (which volatile aggravates) unfortunately makes it even tougher to find race conditions. In my experience, volatile should be avoided. I'd even bet money that some grumpy person has written a volatile considered harmful essay. I Am Not A memory-model expert so consult your local guru, p ___ 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] PEP 3147: PYC Repository Directories
On Mon, Feb 1, 2010 at 13:19, Martin v. Löwis mar...@v.loewis.de wrote: How do you write to a zipfile while others are reading it? On Mon, Feb 1, 2010 at 1:23 PM, Brett Cannon br...@python.org wrote: By hating concurrency (i.e. I don't have an answer which kills my idea). The python I use (win32 2.6.2) does not complain if it cannot read from or write to a .pyc; and thus it handles multiple python processes trying to create .pyc files at the same time. Is the .zip case really any different? Since .pyc files are an optimization, it seems natural and correct that .pyc IO errors pass silently (apologies to Tim). It's an interesting challenge to write the file in such a way that it's safe for a reader and writer to co-exist. Like Brett, I considered an append-only scheme, but one needs to handle the case where the bytecode for a particular magic number changes. At some point you'd need to sweep garbage from the file. All solutions seem unnecessarily complex, and unnecessary since in practice the case should not come up. paul ___ 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] PEP 3147: PYC Repository Directories
The python I use (win32 2.6.2) does not complain if it cannot read from or write to a .pyc; and thus it handles multiple python processes trying to create .pyc files at the same time. Is the .zip case really any different? [ snip discussion of difficulty of writing a sharing-safe update ] On Mon, Feb 1, 2010 at 2:28 PM, Martin v. Löwis mar...@v.loewis.de wrote: So what would you do for concurrent writers, then? The current implementation relies on creat(O_EXCL) to be atomic, so a second writer would just fail. This is but the only IO operation that is guaranteed to be atomic (along with mkdir(2)), so reusing the current approach doesn't work. Sorry, I'm guilty of having assumed that the POSIX API has an operation analogous to win32 CreateFile(GENERIC_WRITE, 0 /* ie, FILE_SHARE_NONE*/). If shared-reader/single-writer semantics are not available, the only other possibility I can think of is to avoid opening the .pyc for write. To write a .pyc one would read it, write and flush updates to a temp file, and rename(). This isn't atomic, but given the invariant that the .pyc always contains consistent data, the new file will also only contain consistent data. Races manifest as updates getting lost. One obvious drawback is that the the .pyc inode would change on every update. paul ___ 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] Extending tuple unpacking
On 10/10/05, Nick Coghlan [EMAIL PROTECTED] wrote: cmd, *args = input.split() These examples also have a reasonable implementation using list.pop(), albeit one that requires more typing. On the plus side, it does not violate DRY and is explicit about the error cases. args = input.split() try: cmd = input.pop(0) except IndexError: cmd = '' def func(*args, **kwds): arg1, arg2, *rest = args # Unpack the positional arguments rest = args# or args[:] if you really did want a copy try: arg1 = rest.pop(0) arg2 = rest.pop(0) except IndexError: raise TypeError(foo() takes at least 2 arguments) paul ___ 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] Explicitly declaring expected exceptions for a block
On 6/20/05, Dmitry Dvoinikov [EMAIL PROTECTED] wrote: Excuse me if I couldn't find that in the existing PEPs, but wouldn't that be useful to have a construct that explicitly tells that we know an exception of specific type could happen within a block, like: ignore TypeError: do stuff [else: do other stuff] If I understand PEP 343 correctly, it allows for easy implementation of part of your request. It doesn't implement the else: clause, but you don't give a use case for it either. class ignored_exceptions(object): def __init__(self, *exceptions): self.exceptions = exceptions def __enter__(self): return None def __exit__(self, type, value, traceback): try: raise type, value, traceback except self.exceptions: pass with ignored_exceptions(SomeError): do stuff I don't see the use, but it's possible. The reason for that being self-tests with lots and lots of little code snippets like this: If you're trying to write tests, perhaps a better use-case would be something like: with required_exception(SomeError): do something that should cause SomeError paul ___ 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
