[issue3125] test_multiprocessing causes test_ctypes to fail

roudkerk <[EMAIL PROTECTED]> added the comment: > I am not sure to understand. Can you elaborate? > How is memory management different between windows and unix? Removing the "if win32" bits will not make shared ctypes objects picklable on unix. Even on windows there are

[issue3125] test_multiprocessing causes test_ctypes to fail

roudkerk <[EMAIL PROTECTED]> added the comment: > But why this is win32 specific? > > Is it because windows cannot fork(), so data has to be copied through > the pickle mechanism? > In this case let's remove the "if win32" statement, and always execute >

[issue3125] test_multiprocessing causes test_ctypes to fail

roudkerk <[EMAIL PROTECTED]> added the comment: This patch to sharedctypes should fix the problem by adding a __reduce_ex__() method to a shared ctype object instead of using copy_reg. -- keywords: +patch Added file: http://bugs.python.org/file10652/sharedctypes.py

[issue3088] test_multiprocessing hangs on OS X 10.5.3

roudkerk <[EMAIL PROTECTED]> added the comment: I suspect the problems with WithManagerTestCondition.notify_all() may have to do with the thread safety of the proxies. If you replace Thread(...) by self.Process(...) in that test then the problem may g

[issue2475] Popen.poll always returns None

roudkerk <[EMAIL PROTECTED]> added the comment: The problem is that os.wait() does not play nicely with subprocess.py. Popen.poll() and Popen.wait() use os.waitpid(pid, ...) which will raise OSError if pid has already been reported by os.wait(). Popen.poll() swallows OSError and by d

[issue1683] Thread local storage and PyGILState_* mucked up by os.fork()

roudkerk added the comment: The included patch against python2.51 fixes the problem for me. -- versions: +Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9076/fork-thread-patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.p

[issue1683] Thread local storage and PyGILState_* mucked up by os.fork()

New submission from roudkerk: I got a report that one of the tests for processing (http://cheeseshop.python.org/pypi/processing) was failing with Fatal Python error: Invalid thread state for this thread when run with a debug interpreter. This appears to be caused by the interaction

[issue1378] fromfd() and dup() for _socket on WIndows

roudkerk added the comment: Currently on Windows set_error() make use of a large array which maps socket error numbers to error messages. This patch (against socketmodule.c from Python 2.6) removes that array and just lets PyErr_SetExcFromWindowsErr() generate the message by using the Win32

[issue1378] fromfd() and dup() for _socket on WIndows

roudkerk added the comment: >From Guido's patch: >if (!DuplicateHandle(GetCurrentProcess(), (HANDLE)handle, > GetCurrentProcess(), &newhandle, > 0, FALSE, DUPLICATE_SAME_ACCESS)) >{ >

[issue1378] fromfd() and dup() for _socket on WIndows

Changes by roudkerk: -- versions: +Python 2.6 -Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1378> __ ___ Python-bugs-list mailing list

[issue1378] fromfd() and dup() for _socket on WIndows

New submission from roudkerk: The patch adds support for _socket.fromfd() and _socket.socket.dup() on Windows. It uses the Win32 DuplicateHandle() function. The patch is to socketmodule.c an test_socket.py. -- files: socket_fromfd.patch messages: 57084 nosy: roudkerk severity: normal