On Sun, Jan 31, 2010 at 5:00 AM, "Martin v. Löwis" <mar...@v.loewis.de> wrote:
>> Agreed this should be discussed in the PEP, but one obvious problem is
>> the speed impact. Picking up a file from a subdirectory is going to
>> introduce less overhead than unpacking it from a zipfile.
>
> There is also the issue of race conditions with multiple simultaneous
> accesses. The original format for the PEP had race conditions for
> multiple simultaneous writers; ZIP will also have race conditions for
> concurrent readers/writers (as any new writer will have to overwrite
> the central directory, making the zip file temporarily unavailable -
> unless they copy it, in which case we are back to writer/writer
> races).
Since a pyc file is just a marshaled code object prefixed with a magic
number and mtime why not change the structure of the pyc (maybe
calling it a pyr file) to store multiple code objects in a marshaled
dictionary. For example:
{ '<MAGIC>': (mtime, code_obj) }
This would eliminate the read-time race condition but still
potentially allow for a write-time race condition if locking isn't
used. The benefit of this approach is that it is no less clear than
pyc is today and doesn't result in n * versions_of_python pyc files.
There is still the overhead of unmarshaling the file to check for a
code object that matches your version. If unmarshaling the entire file
each time is problematic an on-disk format with a short TOC at the
beginning followed by the marshaled data would likely solve the issue.
--
Michael E. Crute
http://mike.crute.org
It is a mistake to think you can solve any major problem just with
potatoes. --Douglas Adams
_______________________________________________
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
