On Thu, Jul 2, 2009 at 4:04 PM, Jean-Paul Calderone<exar...@divmod.com> wrote: > On Thu, 2 Jul 2009 15:47:48 -0700, "Gregory P. Smith" <g...@krypto.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.
I'm probably to blame for this, but IIRC when we did it, lock acquisitions were not interruptible by signals. However, that was before posix threads were even standardized. Nowadays I believe we use pthreads everywhere except on Windows. But I know nearly nothing about pthreads. If pthreads mutex acquisition is (or can easily be made) interruptible by signals I'd be all for adding signal handling to them, assuming it doesn't slow things down much. Also, if there are ways to do the "try to acquire a lock or wait until a given timeout" natively and while handling signals, that would be a great improvement. I'll probably regret saying this within an hour though, -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
