Re: [Python-Dev] Python signal processing question

[Michael Crute]

On Mon, Jul 19, 2010 at 12:11 PM, Scott McCarty scott.mcca...@gmail.com wrote:
 All, I have searched everywhere (mostly the code and a little google) and I
 cannot understand where the SIGKILL signal gets checked when it is set as a
 handler. I have scoured the Modules/signalmodule.c only to find two
 instances of the RuntimeError exception, but I cannot understand how python
 knows when a handler is set for SIGKILL. I understand that this changed in
 2.4 and I am not trying to change it, I just really want to understand where
 this happens. I used grep to find SIGKILL and SIGTERM to see if I could
 determine where the critical difference is, but I cannot figure it out.

 I have about 2 hours of searching around and I can't figure it out, I assume
 it has to rely on some default behaviour in Unix, but I have no idea. I
 don't see a difference between SIGKILL and SIGTERM in the python code, but
 obviously there is some difference. I understand what the difference is in
 Unix/Linux, I just want to see it in the python code. Since python is
 checking at run time to see what signals handlers are added, I know there
 must be a difference.

The signals get initialized at interpreter startup within the initsigs
function (Python/pythonrun.c). By default the interpreter ignores
SIGPIPE, SIGXFZ and SIGXFSZ. Eventually initsignal
(Modules/signalmodule.c) which will loop over an array of all handlers
and set their handlers to the default handler, ignore handler or None,
depending on the default state of the handler as reported by the OS.
After all of that python will register its own signal handler for
SIGINT which raises a KeyboardInterrupt error (you can change this).

By default on Linux SIGKILL gets a None handler since it can not be
handled or ignored (as dictated by the OS) and SIGTERM gets the
default handler which at least under Linux is to terminate the program
without doing any kind of cleanup.

It is worth noting that you can handle SIGTERM but python chooses not
to do this by default.

Doug Hellmann wrote a post about the signal module that is a good
complement to the C code for understanding how signals are handled in
python. http://www.doughellmann.com/PyMOTW/signal/

HTH.

-mike

-- 
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

Re: [Python-Dev] PEP 3147: PYC Repository Directories

[Michael Crute]

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