Opened 11 years ago
Closed 11 years ago
#5833 closed Support Requests (invalid)
once.cpp: call_onces swallows errors from CreateMutexA and WaitForSingleObject
Reported by: | Owned by: | viboes | |
---|---|---|---|
Milestone: | To Be Determined | Component: | thread |
Version: | Boost 1.47.0 | Severity: | Problem |
Keywords: | Cc: | noloader@… |
Description
Index: once.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/thread/src/once.cpp,v retrieving revision 1.27 diff -r1.27 once.cpp 157c157 < HANDLE mutex = CreateMutexA(NULL, FALSE, strm.str().c_str()); ---
HANDLE mutex = CreateMutexA(NULL, FALSE, strm.str().c_str());
160a161,162
if(mutex == NULL)
throw std::runtime_error("Failed to create one-time mutex");
162,164c164,166 < int res = 0; < res = WaitForSingleObject(mutex, INFINITE); < assert(res == WAIT_OBJECT_0); ---
int wait1 = WAIT_OBJECT_0, res = 0; wait1 = WaitForSingleObject(mutex, INFINITE); assert(wait1 == WAIT_OBJECT_0);
186a189,191
if(wait1 != WAIT_OBJECT_0)
throw std::runtime_error("Failed to wait on mutex");
Change History (6)
comment:1 by , 11 years ago
Cc: | added |
---|---|
Component: | None → thread |
Owner: | set to |
follow-up: 3 comment:2 by , 11 years ago
Cc: | added |
---|---|
Owner: | changed from | to
Status: | new → assigned |
Please, could you use the code block so that the proposed pathc is readable, or just explain the problem and attach the patch?
comment:3 by , 11 years ago
Replying to viboes:
Please, could you use the code block so that the proposed pathc is readable, or just explain the problem and attach the patch?
Forget this comment please. The text is readable.
comment:5 by , 11 years ago
Cc: | removed |
---|---|
Type: | Bugs → Support Requests |
Moved to support request until concerned file clarified.
comment:6 by , 11 years ago
Resolution: | → invalid |
---|---|
Status: | assigned → closed |
Closed as it seems this doesn't corresponds to the current Boost.Thread implementation.
assert(res == WAIT_OBJECT_0)
might be too tight -assert(res == WAIT_OBJECT_0 || res == WAIT_ABANDONED_0)
might be a better choice.