Repository navigation
if extended c module is calling Windows API waitForSingleObject, it will block other thread. #47277
Description
| BPO | 3027 |
|---|---|
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2008-06-03.07:18:36.343>
created_at = <Date 2008-06-02.09:53:19.632>
labels = ['interpreter-core']
title = 'if extended c module is calling Windows API waitForSingleObject, it will block other thread.'
updated_at = <Date 2008-06-03.07:18:36.308>
user = 'https://bugs.python.org/patrick'bugs.python.org fields:
activity = <Date 2008-06-03.07:18:36.308>
actor = 'georg.brandl'
assignee = 'none'
closed = True
closed_date = <Date 2008-06-03.07:18:36.343>
closer = 'georg.brandl'
components = ['Interpreter Core']
creation = <Date 2008-06-02.09:53:19.632>
creator = 'patrick'
dependencies = []
files = ['10502']
hgrepos = []
issue_num = 3027
keywords = []
message_count = 3.0
messages = ['67633', '67634', '67648']
nosy_count = 2.0
nosy_names = ['therve', 'patrick']
pr_nums = []
priority = 'normal'
resolution = 'works for me'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue3027'
versions = ['Python 2.5']
Activity
patrick commentedon Jun 2, 2008
The c extend module is as the attached file "WindowsFuncs.cpp", it
wraps some Windows event APIs
The python script is as the attached file "test.py", run that script,
we could find in the new thread, the calling to Windows API
waitForSingleObject will block the main thread printing, that's really
strange.
The output of running is as the attached file "test.output".
therve commentedon Jun 2, 2008
You have to release the GIL. See http://docs.python.org/api/threads.html
for some information.
patrick commentedon Jun 3, 2008
Yes, after wrapping the calling to block operation with marco
Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS, that issue is gone.
Thank you.