This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: native win32 threading primitives
Type: Stage:
Components: Extension Modules Versions:
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: jorend, loewis, tim.peters
Priority: normal Keywords: patch

Created on 2002-01-07 16:34 by jorend, last changed 2022-04-10 16:04 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
winthreading.zip jorend, 2002-01-07 16:34 winthreading source and MSVC6 project files
winthreading.pyd jorend, 2002-01-07 16:37 Compiled winthreading extension
wt_tests.zip jorend, 2002-01-07 17:20 Python test cases for winthreading
winthreading-1.0.zip jorend, 2002-01-08 06:49 winthreading source and setup.py file
Messages (9)
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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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.
History
Date User Action Args
2022-04-10 16:04:51adminsetgithub: 35878
2002-01-07 16:34:42jorendcreate