I think I can answer the "why" question: thread.c is *very* old code, in fact it predates the posix threads standard. When we (actually Sjoerd Mullender) wrote it, we had a number of OS-specific locking APIs to work with and the API was designed to fit all of them. I don't even recall the initial set, but I think it included SGI Irix and and old version of SunOS. So then over time new platforms were added, but adding a new method or parameter to the API was nearly impossible because someone would have to find out how to implement the new feature on all supported platforms. I think the number of platforms has dwindled to two or three (Posix, Windows, and maybe one minority OS?), so now's the time to do it. (IOW I think the idea of the patch is fine.)
Will locks be interruptible with ^C? That is an oft-requested feature which also wasn't supported at that time; what's the situation nowadays? --Guido On Tue, Nov 17, 2009 at 3:46 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > > Hello, > > I've submitted a patch (*) to add an optional timeout to locking operations > (Lock.acquire() etc.). Since it's a pretty basic functionality, I would like > to > know if there was any good reason for not doing it. > > (*) http://bugs.python.org/issue7316 > > Thank you > > Antoine. > > > _______________________________________________ > 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/guido%40python.org > -- --Guido van Rossum (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
