[Patches] [ python-Patches-622537 ] dummy_thread.py implementation

noreply@sourceforge.net noreply@sourceforge.net
Wed, 27 Nov 2002 19:07:52 -0800

Patches item #622537, was opened at 2002-10-13 00:07
You can respond by visiting: 

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: dummy_thread.py implementation

Initial Comment:
As mentioned in Zack Weinberg's Python-dev thread, "A
few lessons from the tempfile.py rewrite", it was
brought up that not having thread in all distributions
is a pain because you have to write around instances of
it not existing.  Guido suggested the compromise of
having a dummy_thread.py so that one could do:

   import thread as _thread
except ImportError:
   import dummy_thread as _thread

This is specific comment can be found at

Well, I decided to implement dummy_thread.py .  I have
tested it against test_thread.py and test_threading.py
by editing the files locally to import dummy_thread as
thread.  All tests did pass.

The only thing that is not necessarily straight-forward
in the implementation is that for non-blocking
lock.acquire() calls, the code actually checks to see
if the lock is available; blocking calls just
automatically acquire the lock since blocking when
there is not real threading would not big good.  =)  It
was also to appease the assert demons in threading.py
for Condition objects since Condition._is_owned() did
not like having lock.acquire() always succeed.

As for adding regression tests, one could just run
test_thread.py specifically against dummy_thread.py . 
The tougher test, though, was getting test_threading.py
to work with threading.py importing dummy_thread.

I am not, as of this exact moment, uploading any
patches to add regression tests since I wrote this on a
whim and I am leaving for vacation on 2002-10-14.  I
will be back by November 1, though, and I can try to
come up with how to integrate regression tests then if
no one has beaten me to it.


>Comment By: Brett Cannon (bcannon)
Date: 2002-11-27 19:07

Logged In: YES 

So  all patches and files needed for dummy_thread to be
accepted into the stdlib are now uploaded.  The various
parts of this patch (which all don't need to be accepted
which is why I did it the way I have) are as follows:

The module:
dummy_thread.py is the module.  test_dummy_thread.py is the
testing suite.

New test files:
Since I had to basically simulate threads, I wrote the tests
as if I was going to test the thread module.  So I wrote
test_dummy_thread.py in such a way that ``test_main()`` can
accept a module to use as the thread implementation.  The
included test_thread.py uses test_dummy_thread.py to test
the thread module.  It is more in-depth then the current
implementation. If  my version of test_thread.py is used,
then Lib/test/output/test_thread will need to be removed (my
testing suite uses PyUnit).  As an aside, dummy_thread.py
does pass the current test_thread.py testing suite.

Changed modules:
added_dummy.diff is a diff that changes Queue, threading,
and tempfile to use dummy_thread when thread is not
available.  They all still pass their tests when using
dummy_thread (dummy_thread has one design decision just  to
pass threading's ``assert`` statements; all info is in the
doc strings).  pydoc can be changed so as to not use
threading if the thread module is not available, but there
are no tests for the module, so I will let the person who
checks this in make the call whether it should be added.  I
tried it and everything seemed to work fine so I personally
think it is safe for pydoc to stay as it is.

libdummythread.tex is my attempt at writing the docs for 
dummy_thread.  Since it basically mirrors thread, I state to
use thread's docs for  API info and explain what 
dummy_thread is for.  doc_dummy.tex adds notes to
libthread.tex and libthreading.tex mentioning dummy_thread
and in threading's case how to make sure  that you only
import threading if you  want only true threading. 
Mentioning Queue's use  of dummy_thread as backup could be
useful, but  since there is no lock-up problems I don't see
the need.

dummy_thread has only one issue with replacing thread in all
cases: blocking I/O.  Both test_asynchat and test_socket
block on their threads because they spawn both server and
client threads that block waiting for  each other.  But both
modules import thread explicitly, so there is no worry with
these modules running with dummy_thread as their thread
implementation.  I also couldn't run test_socketserver
because  I can't run test_normalization.

But other then those three tests, all other tests pass both
under a regular debug  compile and a --without-thread
compile; things just run a little slower.  =)

The 2002-10-13 copy of dummy_thread.py can be deleted (wish
SF would let the patch creator delete files).

This is my first big  patch that touches docs, test, stdlib
modules and has a new doc file.  Just  thought I should warn
you.  =)


You can respond by visiting: