-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Raise an exception if an event signal notifies a failure state on EvtSubscribe #44
Conversation
Signed-off-by: Hiroshi Hatake <[email protected]>
Signed-off-by: Hiroshi Hatake <[email protected]>
60bd65e
to
43148f3
Compare
From this pull type of subscription, we need to add the following actions: 1. Create an EventObject for handling signal events 2. Reset signal when ERROR_NO_MORE_ITEMS from EvtNext This should ensure the windows eventlog collection correctly. Also, we shouldn't specify the INFINITE waiting on WaitForSingleObject because this function is inside of enumerator. So, it causes infinite blocking for this case. ref: https://learn.microsoft.com/en-us/windows/win32/wes/subscribing-to-events#pull-subscriptions Signed-off-by: Hiroshi Hatake <[email protected]>
4eeb513
to
d8299fb
Compare
(From #44 (comment)) Sorry if I'm not understanding it correctly. I don't see a problem with the current design, where If we implement it as in this example, shouldn't we add a new feature to pass a callback and have it keep listening? |
This is because we didn't checked the internal state of subscriptions. The current mechanism is just passing no working signal into EvtSubscribe and no one checked the result. |
The current behavior of around the signal is: CreateEventA reference: https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-createeventa |
@daipom Are my comments answered your question? Thanks for your comment. |
@cosmo0920 Thanks for your explanation!
In the current design, it looks like it is unnecessary to check it.
I'm wondering if this is really the expected behavior in the current design. In this example, it is designed to call a function in response to event notifications. |
The example needs to handle the signal in order to respond to the state. On the other hand, It would be good to use a signal like this example so that it can respond to the state without using a timer. |
To tell the truth, I have same impression on this pull request. |
I don't want the code to be unnecessarily complex, but if it is expected to have advantages such as being able to detect errors that have been overlooked so far with |
I wondering if we could detect internal error of EvtSubscribe. In push subscription case, the registered callback in EvtSubscribe will return failure state with: EvtSubscribeActionError and not ERROR_EVT_QUERY_RESULT_STALE status. With the current implementation is 99% sure of the usecase but high frequently flowing rate environment could generate such stales from invalid statuses so I wanted to capture them. |
I see. Now, I understand the point. Thanks. Is it safe to do |
I intended the following procedure here:
So, |
Oh, I'm sorry.
However, I still have concerns about the timing of doing For example, As @ashie says, we can't know the implementation of Windows, so it is fine that we can possibly get an error with this though it may not make sense. As a side note, I wonder if it should be done at the static VALUE
rb_winevt_subscribe_each(VALUE self)
{
RETURN_ENUMERATOR(self, 0, 0);
{Confirm the event}
while (rb_winevt_subscribe_next(self)) {
rb_ensure(
rb_winevt_subscribe_each_yield, self, rb_winevt_subscribe_close_handle, self);
}
{Reset the event}
return Qnil;
} |
It is totally not making sense.
We should leave a comment for this side note instead of the proposed each loop level of acknowledged and reset manually the signal.
This is the real reason what I set up to create with bManualReset is TRUE. Otherwise, we didn't recognize the internal invalid state through the signal. EvtSubscribe's SignalEvent agrument requests to register a signal event which is created with bManualReset and bInitialState are TRUE. |
Signed-off-by: Hiroshi Hatake <[email protected]>
801f1d9
to
f9f833d
Compare
Signed-off-by: Hiroshi Hatake <[email protected]>
Could you please change the PR title to make it clear the purpose? |
I changed this PR title. Is there anything to be needed things to fulfill to get merged? |
LGTM. Thanks! |
I'm going to release it as v0.10.2, OK? |
Sure. Let's go ahead! |
Done. |
With event signal system, we're able to check the status of the event subscriptions.
This could be helpful for detecting failure of the subscribed handles.
This pull type of subscription,
we need to add the following actions:
This should ensure the windows eventlog collection correctly.
Also, we shouldn't specify the INFINITE waiting on WaitForSingleObject
because this function is inside of enumerator.
So, it causes infinite blocking for this case.