cpython/Python/thread_nt.h

312 lines
6.6 KiB
C
Raw Normal View History

1995-01-17 12:29:31 -04:00
/* This code implemented by Dag.Gruneau@elsa.preseco.comm.se */
/* Fast NonRecursiveMutex support by Yakov Markovitch, markovitch@iso.ru */
/* Eliminated some memory leaks, gsw@agere.com */
1995-01-17 12:29:31 -04:00
#include <windows.h>
#include <limits.h>
#ifdef HAVE_PROCESS_H
#include <process.h>
#endif
1995-01-17 12:29:31 -04:00
typedef struct NRMUTEX {
LONG owned ;
DWORD thread_id ;
HANDLE hevent ;
} NRMUTEX, *PNRMUTEX ;
BOOL
InitializeNonRecursiveMutex(PNRMUTEX mutex)
{
mutex->owned = -1 ; /* No threads have entered NonRecursiveMutex */
mutex->thread_id = 0 ;
mutex->hevent = CreateEvent(NULL, FALSE, FALSE, NULL) ;
return mutex->hevent != NULL ; /* TRUE if the mutex is created */
}
VOID
DeleteNonRecursiveMutex(PNRMUTEX mutex)
{
/* No in-use check */
CloseHandle(mutex->hevent) ;
mutex->hevent = NULL ; /* Just in case */
}
DWORD
EnterNonRecursiveMutex(PNRMUTEX mutex, BOOL wait)
{
/* Assume that the thread waits successfully */
DWORD ret ;
/* InterlockedIncrement(&mutex->owned) == 0 means that no thread currently owns the mutex */
if (!wait)
{
if (InterlockedCompareExchange(&mutex->owned, 0, -1) != -1)
return WAIT_TIMEOUT ;
ret = WAIT_OBJECT_0 ;
}
else
ret = InterlockedIncrement(&mutex->owned) ?
/* Some thread owns the mutex, let's wait... */
WaitForSingleObject(mutex->hevent, INFINITE) : WAIT_OBJECT_0 ;
mutex->thread_id = GetCurrentThreadId() ; /* We own it */
return ret ;
}
BOOL
LeaveNonRecursiveMutex(PNRMUTEX mutex)
{
/* We don't own the mutex */
mutex->thread_id = 0 ;
return
InterlockedDecrement(&mutex->owned) < 0 ||
SetEvent(mutex->hevent) ; /* Other threads are waiting, wake one on them up */
}
PNRMUTEX
AllocNonRecursiveMutex(void)
{
PNRMUTEX mutex = (PNRMUTEX)malloc(sizeof(NRMUTEX)) ;
if (mutex && !InitializeNonRecursiveMutex(mutex))
{
free(mutex) ;
mutex = NULL ;
}
return mutex ;
}
void
FreeNonRecursiveMutex(PNRMUTEX mutex)
{
if (mutex)
{
DeleteNonRecursiveMutex(mutex) ;
free(mutex) ;
}
}
long PyThread_get_thread_ident(void);
1995-01-17 12:29:31 -04:00
/*
* Initialization of the C package, should not be needed.
*/
static void
PyThread__init_thread(void)
1995-01-17 12:29:31 -04:00
{
}
/*
* Thread support.
*/
typedef struct {
void (*func)(void*);
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 01:40:45 -03:00
void *arg;
long id;
HANDLE done;
} callobj;
static int
bootstrap(void *call)
{
callobj *obj = (callobj*)call;
/* copy callobj since other thread might free it before we're done */
void (*func)(void*) = obj->func;
void *arg = obj->arg;
obj->id = PyThread_get_thread_ident();
ReleaseSemaphore(obj->done, 1, NULL);
func(arg);
return 0;
}
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 01:40:45 -03:00
long
PyThread_start_new_thread(void (*func)(void *), void *arg)
1995-01-17 12:29:31 -04:00
{
Py_uintptr_t rv;
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 01:40:45 -03:00
callobj obj;
1995-01-17 12:29:31 -04:00
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 01:40:45 -03:00
dprintf(("%ld: PyThread_start_new_thread called\n",
PyThread_get_thread_ident()));
1995-01-17 12:29:31 -04:00
if (!initialized)
PyThread_init_thread();
1995-01-17 12:29:31 -04:00
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 01:40:45 -03:00
obj.id = -1; /* guilty until proved innocent */
obj.func = func;
obj.arg = arg;
obj.done = CreateSemaphore(NULL, 0, 1, NULL);
if (obj.done == NULL)
return -1;
rv = _beginthread(bootstrap,
Py_SAFE_DOWNCAST(_pythread_stacksize,
Py_ssize_t, int),
&obj);
if (rv == (Py_uintptr_t)-1) {
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 01:40:45 -03:00
/* I've seen errno == EAGAIN here, which means "there are
* too many threads".
*/
dprintf(("%ld: PyThread_start_new_thread failed: %p errno %d\n",
PyThread_get_thread_ident(), (void*)rv, errno));
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 01:40:45 -03:00
obj.id = -1;
1995-01-17 12:29:31 -04:00
}
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 01:40:45 -03:00
else {
dprintf(("%ld: PyThread_start_new_thread succeeded: %p\n",
PyThread_get_thread_ident(), (void*)rv));
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 01:40:45 -03:00
/* wait for thread to initialize, so we can get its id */
WaitForSingleObject(obj.done, INFINITE);
assert(obj.id != -1);
}
CloseHandle((HANDLE)obj.done);
return obj.id;
1995-01-17 12:29:31 -04:00
}
/*
* Return the thread Id instead of an handle. The Id is said to uniquely identify the
* thread in the system
*/
long
PyThread_get_thread_ident(void)
1995-01-17 12:29:31 -04:00
{
if (!initialized)
PyThread_init_thread();
1995-01-17 12:29:31 -04:00
return GetCurrentThreadId();
}
static void
do_PyThread_exit_thread(int no_cleanup)
1995-01-17 12:29:31 -04:00
{
dprintf(("%ld: PyThread_exit_thread called\n", PyThread_get_thread_ident()));
1995-01-17 12:29:31 -04:00
if (!initialized)
if (no_cleanup)
_exit(0);
else
exit(0);
_endthread();
1995-01-17 12:29:31 -04:00
}
void
PyThread_exit_thread(void)
1995-01-17 12:29:31 -04:00
{
do_PyThread_exit_thread(0);
1995-01-17 12:29:31 -04:00
}
void
PyThread__exit_thread(void)
1995-01-17 12:29:31 -04:00
{
do_PyThread_exit_thread(1);
1995-01-17 12:29:31 -04:00
}
#ifndef NO_EXIT_PROG
static void
do_PyThread_exit_prog(int status, int no_cleanup)
1995-01-17 12:29:31 -04:00
{
dprintf(("PyThread_exit_prog(%d) called\n", status));
1995-01-17 12:29:31 -04:00
if (!initialized)
if (no_cleanup)
_exit(status);
else
exit(status);
}
void
PyThread_exit_prog(int status)
1995-01-17 12:29:31 -04:00
{
do_PyThread_exit_prog(status, 0);
1995-01-17 12:29:31 -04:00
}
void
PyThread__exit_prog(int status)
1995-01-17 12:29:31 -04:00
{
do_PyThread_exit_prog(status, 1);
1995-01-17 12:29:31 -04:00
}
#endif /* NO_EXIT_PROG */
/*
* Lock support. It has too be implemented as semaphores.
* I [Dag] tried to implement it with mutex but I could find a way to
* tell whether a thread already own the lock or not.
*/
PyThread_type_lock
PyThread_allocate_lock(void)
1995-01-17 12:29:31 -04:00
{
PNRMUTEX aLock;
1995-01-17 12:29:31 -04:00
dprintf(("PyThread_allocate_lock called\n"));
1995-01-17 12:29:31 -04:00
if (!initialized)
PyThread_init_thread();
1995-01-17 12:29:31 -04:00
aLock = AllocNonRecursiveMutex() ;
1995-01-17 12:29:31 -04:00
dprintf(("%ld: PyThread_allocate_lock() -> %p\n", PyThread_get_thread_ident(), aLock));
1995-01-17 12:29:31 -04:00
return (PyThread_type_lock) aLock;
1995-01-17 12:29:31 -04:00
}
void
PyThread_free_lock(PyThread_type_lock aLock)
1995-01-17 12:29:31 -04:00
{
dprintf(("%ld: PyThread_free_lock(%p) called\n", PyThread_get_thread_ident(),aLock));
1995-01-17 12:29:31 -04:00
FreeNonRecursiveMutex(aLock) ;
1995-01-17 12:29:31 -04:00
}
/*
* Return 1 on success if the lock was acquired
*
* and 0 if the lock was not acquired. This means a 0 is returned
* if the lock has already been acquired by this thread!
*/
int
PyThread_acquire_lock(PyThread_type_lock aLock, int waitflag)
1995-01-17 12:29:31 -04:00
{
int success ;
1995-01-17 12:29:31 -04:00
dprintf(("%ld: PyThread_acquire_lock(%p, %d) called\n", PyThread_get_thread_ident(),aLock, waitflag));
1995-01-17 12:29:31 -04:00
success = aLock && EnterNonRecursiveMutex((PNRMUTEX) aLock, (waitflag ? INFINITE : 0)) == WAIT_OBJECT_0 ;
1995-01-17 12:29:31 -04:00
dprintf(("%ld: PyThread_acquire_lock(%p, %d) -> %d\n", PyThread_get_thread_ident(),aLock, waitflag, success));
1995-01-17 12:29:31 -04:00
return success;
}
void
PyThread_release_lock(PyThread_type_lock aLock)
1995-01-17 12:29:31 -04:00
{
dprintf(("%ld: PyThread_release_lock(%p) called\n", PyThread_get_thread_ident(),aLock));
1995-01-17 12:29:31 -04:00
if (!(aLock && LeaveNonRecursiveMutex((PNRMUTEX) aLock)))
dprintf(("%ld: Could not PyThread_release_lock(%p) error: %ld\n", PyThread_get_thread_ident(), aLock, GetLastError()));
1995-01-17 12:29:31 -04:00
}
/* minimum/maximum thread stack sizes supported */
#define THREAD_MIN_STACKSIZE 0x8000 /* 32kB */
#define THREAD_MAX_STACKSIZE 0x10000000 /* 256MB */
/* set the thread stack size.
* Return 0 if size is valid, -1 otherwise.
*/
static int
_pythread_nt_set_stacksize(size_t size)
{
/* set to default */
if (size == 0) {
_pythread_stacksize = 0;
return 0;
}
/* valid range? */
if (size >= THREAD_MIN_STACKSIZE && size < THREAD_MAX_STACKSIZE) {
_pythread_stacksize = size;
return 0;
}
return -1;
}
#define THREAD_SET_STACKSIZE(x) _pythread_nt_set_stacksize(x)