Commit Graph

33 Commits

Author SHA1 Message Date
Kristján Valur Jónsson b4c285a25b Fix NonRecursiveMutex on x64. The signature of the faux-InterlockedCompareExchange function was wrong: It works with LONG and not PVOID objects, and it needs to have the target marked as volatile. Further, it is not needed at all for x64 targets, since that platform always has the real McCoy. 2007-05-07 18:28:12 +00:00
Kristján Valur Jónsson 5e4e31f76a Fix various minor issues discovered with static analysis using Visual Studio 2005 Team System.
Removed obsolete comment, since .dll modules are no longer supported on windows, only .pyd.
2007-04-21 12:46:49 +00:00
Andrew MacIntyre 9291332de1 Patch #1454481: Make thread stack size runtime tunable.
Heavily revised, comprising revisions:
46640 - original trunk revision (backed out in r46655)
46647 - markup fix (backed out in r46655)
46692:46918 merged from branch aimacintyre-sf1454481

branch tested on buildbots (Windows buildbots had problems
not related to these changes).
2006-06-13 15:04:24 +00:00
Martin v. Löwis 0e8bd7e1cc Patch #1495999: Part two of Windows CE changes.
- update header checks, using autoconf
- provide dummies for getenv, environ, and GetVersion
- adjust MSC_VER check in socketmodule.c
2006-06-10 12:23:46 +00:00
Tim Peters 28eeefe566 Revert revisions:
46640 Patch #1454481:  Make thread stack size runtime tunable.
46647 Markup fix

The first is causing many buildbots to fail test runs, and there
are multiple causes with seemingly no immediate prospects for
repairing them.  See python-dev discussion.

Note that a branch can (and should) be created for resolving these
problems, like

svn copy svn+ssh://svn.python.org/python/trunk -r46640 svn+ssh://svn.python.org/python/branches/NEW_BRANCH

followed by merging rev 46647 to the new branch.
2006-06-04 23:52:47 +00:00
Andrew MacIntyre 63f0db682e clean up function declarations to conform to PEP-7 style. 2006-06-04 12:59:59 +00:00
Andrew MacIntyre 6539d2d3c7 Patch #1454481: Make thread stack size runtime tunable. 2006-06-04 12:31:09 +00:00
Martin v. Löwis a43190bc78 Patch #1492356: Port to Windows CE (patch set 1). 2006-05-22 09:15:18 +00:00
Martin v. Löwis 18e165558b Merge ssize_t branch. 2006-02-15 17:27:45 +00:00
Georg Brandl af410b510d bug [ 1234979 ] Lock.acquire treats only 1 as True 2005-07-08 22:26:13 +00:00
Tim Peters 2e7e7df969 An Anonymous Coward on c.l.py posted a little program with bizarre
behavior, creating many threads very quickly.  A long debugging session
revealed that the Windows implementation of PyThread_start_new_thread()
was choked with "laziness" errors:

1. It checked MS _beginthread() for a failure return, but when that
   happened it returned heap trash as the function result, instead of
   an id of -1 (the proper error-return value).

2. It didn't consider that the Win32 CreateSemaphore() can fail.

3. When creating a great many threads very quickly, it's quite possible
   that any particular bootstrap call can take virtually any amount of
   time to return.  But the code waited for a maximum of 5 seconds, and
   didn't check to see whether the semaphore it was waiting for got
   signaled.  If it in fact timed out, the function could again return
   heap trash as the function result.  This is actually what confused
   the test program, as the heap trash usually turned out to be 0, and
   then multiple threads all got id 0 simultaneously, confusing the
   hell out of threading.py's _active dict (mapping id to thread
   object).  A variety of baffling behaviors followed from that.

WRT #1 and #2, error returns are checked now, and "thread.error: can't
start new thread" gets raised now if a new thread (or new semaphore)
can't be created.  WRT #3, we now wait for the semaphore without a
timeout.

Also removed useless local vrbls, folded long lines, and changed callobj
to a stack auto (it was going thru malloc/free instead, for no discernible
reason).

Bugfix candidate.
2003-07-04 04:40:45 +00:00
Tim Peters e64ef931d6 SF patch 522961: Leak in Python/thread_nt.h, from Gerald S. Williams.
A file-static "threads" dict mapped thread IDs to Windows handles, but
was never referenced, and entries never got removed.  This gets rid of
the YAGNI-dict entirely.
Bugfix candidate.
2002-02-28 21:34:34 +00:00
Fred Drake 7bb1c9a11d Remove the unused & broken PyThread_*_sema() functions and related constants.
This closes SF patch #504215.
2002-01-19 22:02:55 +00:00
Guido van Rossum 2c40adb1e4 Fix a bug in the previous checkin. The wrong bootstrap function was
passed to _beginthread().
2001-10-16 21:50:04 +00:00
Guido van Rossum 3c28863e08 Partial patch from SF #452266, by Jason Petrone.
This changes Pythread_start_thread() to return the thread ID, or -1
for an error.  (It's technically an incompatible API change, but I
doubt anyone calls it.)
2001-10-16 21:13:49 +00:00
Tim Peters 79248aa1e4 SF bug [#456252] Python should never stomp on [u]intptr_t.
pyport.h:  typedef a new Py_intptr_t type.
    DELICATE ASSUMPTION:  That HAVE_UINTPTR_T implies intptr_t is
    available as well as uintptr_t.  If that turns out not to be
    true, things must get uglier (C99 wants both, so I think it's
    an assumption we're *likely* to get away with).
thread_nt.h, PyThread_start_new_thread:  MS _beginthread is documented
    as returning unsigned long; no idea why uintptr_t was being used.
Others:  Always use Py_[u]intptr_t, never [u]intptr_t directly.
2001-08-29 21:37:10 +00:00
Guido van Rossum 8586991099 REMOVED all CWI, CNRI and BeOpen copyright markings.
This should match the situation in the 1.6b1 tree.
2000-09-01 23:29:29 +00:00
Fredrik Lundh 6947d0b65e -- from Trent Mick: [Patch #101010] replace use of INT_PTR
with uintptr_t (fix MSVC 5.0 build)
2000-08-07 20:16:28 +00:00
Thomas Wouters f70ef4f860 Mass ANSIfication of function definitions. Doesn't cover all 'extern'
declarations yet, those come later.
2000-07-22 18:47:25 +00:00
Guido van Rossum ffcc3813d8 Change copyright notice - 2nd try. 2000-06-30 23:58:06 +00:00
Guido van Rossum fd71b9e9d4 Change copyright notice. 2000-06-30 23:50:40 +00:00
Fred Drake a44d353e2b Trent Mick <trentm@activestate.com>:
The common technique for printing out a pointer has been to cast to a long
and use the "%lx" printf modifier. This is incorrect on Win64 where casting
to a long truncates the pointer. The "%p" formatter should be used instead.

The problem as stated by Tim:
> Unfortunately, the C committee refused to define what %p conversion "looks
> like" -- they explicitly allowed it to be implementation-defined. Older
> versions of Microsoft C even stuck a colon in the middle of the address (in
> the days of segment+offset addressing)!

The result is that the hex value of a pointer will maybe/maybe not have a 0x
prepended to it.


Notes on the patch:

There are two main classes of changes:
- in the various repr() functions that print out pointers
- debugging printf's in the various thread_*.h files (these are why the
patch is large)


Closes SourceForge patch #100505.
2000-06-30 15:01:00 +00:00
Fredrik Lundh 34a96371c3 - workaround to make 1.6 build under MSVC 5.0. hopefully,
trent (who broke it in the first place ;-) will come up
  with a cleaner solution.
2000-06-29 17:25:30 +00:00
Guido van Rossum 582acece2e Trent Mick's Win64 changes: size_t vs. int or long; also some overflow
tests.
2000-06-28 22:07:35 +00:00
Guido van Rossum ede8c6eea1 Bill Tutt:
Calling Sleep(0) for a spinlock can cause a priority inversion, adding
comments to explain what's going on.
2000-05-11 12:53:51 +00:00
Guido van Rossum 4cea605e75 Quick fix by Mark Hammond -- Yakov changed a dprintf call but it was
referencing an undefined variable, so we better change it back.
2000-05-05 14:29:59 +00:00
Guido van Rossum 706262bde0 Fast NonRecursiveMutex support by Yakov Markovitch, markovitch@iso.ru,
who wrote:

Here's the new version of thread_nt.h.  More particular, there is a
new version of thread lock that uses kernel object (e.g. semaphore)
only in case of contention; in other case it simply uses interlocked
functions, which are faster by the order of magnitude.  It doesn't
make much difference without threads present, but as soon as thread
machinery initialised and (mostly) the interpreter global lock is on,
difference becomes tremendous.  I've included a small script, which
initialises threads and launches pystone.  With original thread_nt.h,
Pystone results with initialised threads are twofold worse then w/o
threads.  With the new version, only 10% worse.  I have used this
patch for about 6 months (with threaded and non-threaded
applications).  It works remarkably well (though I'd desperately
prefer Python was free-threaded; I hope, it will soon).
2000-05-04 18:47:15 +00:00
Guido van Rossum bffd683f73 The rest of the changes by Trent Mick and Dale Nagata for warning-free
compilation on NT Alpha.  Mostly added casts etc.
2000-01-20 22:32:56 +00:00
Guido van Rossum 65d5b5763c Thanks to Chris Herborth, the thread primitives now have proper Py*
names in the source code (they already had those for the linker,
through some smart macros; but the source still had the old, un-Py names).
1998-12-21 19:32:43 +00:00
Guido van Rossum 49b1226781 Use _beginthread() and _endthread() in favor of CreateThread() and
ExitThread().  As discussed in c.l.p, this takes care of
initialization and finalization of thread-local storage allocated by
the C runtime system.  Not sure whether non-MS compilers grok this
though (but who cares :-).
1997-08-14 20:12:58 +00:00
Guido van Rossum d266eb460e New permission notice, includes CNRI. 1996-10-25 14:44:06 +00:00
Guido van Rossum cf1474b73a Sjoerd's thread changes (including down_sema typo fix).
Note: waitflag not supported on NT.
1996-10-08 14:17:53 +00:00
Guido van Rossum c3f82b6b8a nt thread support 1995-01-17 16:29:31 +00:00