On Thu, 2 Jul 2009 15:47:48 -0700, "Gregory P. Smith" <g...@krypto.org> wrote:
On Mon, Jun 29, 2009 at 2:28 PM, "Martin v. Löwis"<mar...@v.loewis.de> wrote:
AFAIK, ignoring EINTR doesn't preclude the calling of signal handlers.
This is my understanding as well - so I don't think Python actually
"swallows" the signal.
A great example is reading from a socket. Whether or not it can be
interrupted depends on the platform, so catching Ctrl+C often requires
a timeout loop.
Also, remember that signals are asynchronous in the sense that they
are handled outside the normal execution flow of a program. Checking
for EINTR probably isn't the best way to determine if a signal has
been sent to the program.
I think it would be reasonable to support "asynchronous" exceptions,
and Python supports SIGINT fairly well most of the time.
It might be possible to support keyboard interrupts throughout
the system, but changing Python to do so could also cause
incompatibilities. So any change must be done with greatest care,
but simultaneously, should also try to arrange to cover all cases.
Regards,
Martin
_______________________________________________
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/greg%40krypto.org
If you want signals to actually be handled in a timely manner, its
best to leave the main thread of the program alone as a signal
handling thread that just spends its time in a loop of time.sleep(123)
calls rather than blocking on any sort of lock. Spawn other threads
to do the actual work in your program. Signals are delivered
indirectly in the existing CPython implementation by setting an
internal flag that the main interpreter thread polls on occasion so
blocking calls that do not interrupt and return early being called
from the main thread will effectively block signals.
Yes, this is all true now. The question is why the implementation
works that way, and whether it is desirable to keep it working that
way.
Considering *some* of the lock implementations make themselves not
interruptable by threads while others don't bother, it seems like
*some* change to the status quo is desirable.
Jean-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
