| Date: | June 6, 2005 / year-entry #140 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20050606-34/?p=35433 |
| Comments: | 14 |
| Summary: | This quick puzzle floated past one of our internal discussion groups. // in process A hEventA = CreateEvent(NULL, FALSE, TRUE, TEXT("MyNamedEvent")); // in process B hEventB = OpenEvent(EVENT_MODIFY_STATE, FALSE, TEXT("MyNamedEvent")); WaitForSingleObject(hEventB, INFINITE); In Process B, the OpenEvent succeeds, but the WaitForSingleObject returns immediately instead of waiting. Explain. [Correction: I confused the matter by passing TRUE as... |
This quick puzzle floated past one of our internal discussion groups.
// in process A
hEventA = CreateEvent(NULL, FALSE, TRUE, TEXT("MyNamedEvent"));
// in process B
hEventB = OpenEvent(EVENT_MODIFY_STATE, FALSE, TEXT("MyNamedEvent"));
WaitForSingleObject(hEventB, INFINITE);
In Process B, the
[Correction: I confused the matter by passing |
Comments (14)
Comments are closed. |
Am I missing something or is just that the event is simply created as signaled (the third param in CreateEvent) so Wait… function is not supposed to wait by design?
You need to request the SYNCHRONIZE standard access right to an object in order to be able to use WaitForXxx on it. This was not done with the OpenEvent() call — the handle returned by OpenEvent here can only be used with SetEvent/PulseEvent/ResetEvent.
Because the event is created in a signaled state (3rd parameter of TRUE). The wait in the 2nd process will see that and return.
CreateEvent’s third parameter is bInitialState: "If this parameter is TRUE, the initial state of the event object is signaled; otherwise, it is nonsignaled." (MSDN)
Here, it is TRUE, hence the event is in the signaled state.
Now, "The WaitForSingleObject function returns when the specified object is in the signaled state or the time-out interval elapses." (MSDN)
So, WaitForSingleObject returns.
Or did I miss something?
It seems to me as if both AC’s and skywings comments are correct. Assuming that hEventA is created first, then even if the desired access for open event was (EVENT_MODIFY_STATE | SYNCHRONIZE) the wait would return immediately. The MSDN docs also say that the event ought to have a "Local" or "Global" prefix to cope with fast user switching.
The event existed prior to the call to CreateEvent (from process C). Process C created this as a Manual Reset Event initially set. The params for the type of event and its state are ignored in Process A since the event already exists.
Well you opened the event with EVENT_MODIFY_STATE but not with SYNCHRONIZE. So you can set the event but the handle that you got back with the OpenEvent call does not have permissions to wait on it.
This musters as a puuzzle in Microsoft? I am really surprised
The desired access param for the OpenEvent call should additionally have SYNCHRONIZE rights in order to use the handle in a WaitForSingleObject, right?
What does WaitForSingleObject return?
The 3rd parameter of the CreateEvent function states that the initial condition of the event will be set to this, which is in this case TRUE. WaitForSingleObject see that the event has been singled therefore return immediately.
Re: the initial confusion: Even the first time I saw CreateEvent (it was really long long ago) I found these two BOOL parameters very, very unlucky. I never tried to remember which is which. I immediatelly made two my functions like CreateManualResetEvent and CreateAutoResetEvent. One BOOL less, the remaining one was then clearly the initial state, and the nature of the event was also readable and easy to be found with "Find in files".
Alternatively, the second parameter should have been made accepting some EV_MANUAL or EV_AUTO constants and not BOOL. Of course it can’t be changed anymore, but I wanted to point at it as the example of the unlucky design decision.
If the named event already exists CreateEvent does not fail, as one may expect, but rather returns a handle to the already created object. In the case I would imagine that the event was created by another (possibly malicious) process that set the event on creation.
Watch your access masks.
Tuesday, June 07, 2005 7:39 AM by AC
> I found these two BOOL parameters very, very
> unlucky.
Actually one is bad enough, like an MFC function that copies data between UI controls and class variables. Which direction is TRUE and which direction is FALSE?
> Alternatively, the second parameter should
> have been made accepting some EV_MANUAL or
> EV_AUTO constants and not BOOL. Of course it
> can’t be changed anymore,
Yes it can. For backwards compatibility the BOOL values will still be accepted, but additional definitions can be added for human-readable enum values or macros. It isn’t even necessary to change Microsoft’s DLLs. Just a change to .h files and MSDN pages can make it possible for programmers to add more human-readability to new code.