| msg38662 - (view) |
Author: Jason Orendorff (jorend) |
Date: 2002-01-07 16:34 |
| The "threading" module provides five synchronization primitives: Lock, RLock, Condition, Semaphore, and Event. This patch is a module, "winthreading", that provides native C implementations (using Win32 directly) of these objects. Benchmark code runs several times to several hundred times faster using winthreading. winthreading.c is intended as a drop-in replacement for these five pieces of threading.py: # At the end of threading.py; replace # Python synch primitives with native version, # if available. try: from winthreading import * except ImportError: pass The ZIP file attached includes source and MSVC6 project files. The source is compatible with Python 2.2. A prebuilt .PYD will follow. |
|
|
| msg38663 - (view) |
Author: Jason Orendorff (jorend) |
Date: 2002-01-07 16:37 |
| Logged In: YES user_id=18139 Prebuilt .PYD file, as promised. |
|
|
| msg38664 - (view) |
Author: Jason Orendorff (jorend) |
Date: 2002-01-07 17:20 |
| Logged In: YES user_id=18139 Test cases attached. To run them, put winthreading.pyd in your PYTHONPATH and run (for example) python test_rlock.py Each test takes a few seconds to a minute to run on my box; there's a lot of mysterious output, followed by: threading: [2.5829999446868896, ...] average: 2.62159998417 winthreading: [0.12999999523162842, ...] average: 0.122199988365 performance gain: 95.339% winthreading is 21.5 times faster! If you are brave, try modifying test_condition_2.py a bit. Change access.wait() to access.wait(50000) on lines 25 and 39; and see what happens. (If you are not quite that brave, you might want to adjust nloops, on line 46, down to about 500.) |
|
|
| msg38665 - (view) |
Author: Jason Orendorff (jorend) |
Date: 2002-01-08 06:49 |
| Logged In: YES user_id=18139 Better source distribution attached. |
|
|
| msg38666 - (view) |
Author: Martin v. Löwis (loewis) *  |
Date: 2002-11-22 08:44 |
| Logged In: YES user_id=21627 Jason, in this form, the patch is not acceptable. First of all, it is no patch, and it doesn't integrate with the rest of Python's threading libraries. This is all fine if you want to distribute this as a separate package (which I would encourage you to do). If you want to have this become part of Python, you need to: - modify the builtin thread module to expose your primitives, - modify the threading module to use these primitives if possible, - provide documentation for these new functions - possible provide support for these primitives for other threading libraries (this is optional if your documentation points out that these primitives are available only on windows). Please let us know how you would like to proceed with this. |
|
|
| msg38667 - (view) |
Author: Jason Orendorff (jorend) |
Date: 2002-11-23 15:26 |
| Logged In: YES user_id=18139 loewis, Thank you for the comments. You are right that the attachment here is not a patch. I'd like to proceed just as you suggest, if there's actually some level of interest in this. Is there? I mean, if you can find someone who would actually like me to do this, I'll be happy to oblige. I hope that doesn't seem too unreasonable. :-) Also: loewis, I have probably misunderstood you, but I think the code integrates quite well with Python's existing threading module. There's no new functionality, just native implementations of existing functionality. In this respect it's similar to the old strop module (and would, likewise, require only a little documentation). Cheers! |
|
|
| msg38668 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2002-11-23 16:40 |
| Logged In: YES user_id=21627 I don't know anybody who is interested in this functionality. So I'll just close this patch as rejected. As for similarities with strop: This might indeed be the case. If you had a Python version without the strop module, and you just add the strop module, then it would be useless: no existing application would import strop, and no application should import strop. Instead, to make strop useful, one had to add from strop import * to string.py. This I would call integration of strop to Python. Similar integration would be necessary for your module: it should be possible that existing applications make use of the new primitives, without changing a single line in these applications. To make that happen, you need to actually change the Python library - merely adding a module won't help, since the module won't be used. |
|
|
| msg38669 - (view) |
Author: Jason Orendorff (jorend) |
Date: 2002-11-23 21:28 |
| Logged In: YES user_id=18139 Cool, I understand you now. Yes, closing the patch is probably best. Thanks. |
|
|
| msg38670 - (view) |
Author: Tim Peters (tim.peters) * |
Date: 2002-11-24 05:32 |
| Logged In: YES user_id=31435 I encouraged Jason to submit this to begin with, but haven't been able to make time to look at it. I have even less time now, alas. threading.py was always *intended* to support platform-specific more-efficient implementations: that's why, e.g., RLock and Condition and Semaphore are functions instead of classes -- functions can easily be overridden by platform-specific versions without backward compatibility worries. Guido was quite deliberate about this when threading.py was first written. Jason, maybe Mark Hammond could make time to review a proper patch. I believe threading is very common in apps using the Win32 extensions, and boosting the performance of those could be a real benefit. I always liked this idea, but am spread too thin to follow up on it. |
|
|