Phillip Sitbon <phillip.sitbon+python-...@gmail.com> added the comment:
> I'm not competent to review Windows-specific stuff, but > some style notes: > - your indentation is inconsistent with the original file > (you should use tabs) > - please don't use any C++-style comments Thanks- I was only supplying the code for testing purposes, but I will clean it up anyway... and read the style guide closer of course :) > This isn't obvious to me. I do care about what threading.Lock does, > but still fail to see why we can't just slap on a criticial section > and call it done. If it were up to me, I'd say move forward with breaking the current functionality. I guess my statement of "obviously" was that breaking it outright would cause people to complain. After I got to thinking about it that way, making GIL locking free from any other API seemed like it would give more leeway for performance improvement. If anyone is using the semaphore-like features of threading.Lock, they'd likely be better off using threading.Semaphore anyway :) There are some places where the core code would have to change in order to reflect the differences, but otherwise it would be a significant improvement to the GIL under high concurrency and not much of a change for a single thread. On the positive side, a global change means that other core code using locks will also see a speedup with critical sections as the default thread lock. So I guess my main point is that somehow, whether separate from or within the thread lock API, the GIL should be a critical section. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6132> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
