-1

I have a working piece of code on main function in Windows with C++ like:

some_handle = dll_generate_handle;
while(true) {
    if(WaitForSingleObject(some_handle,100)){
          //CODE I AM INTERESTED ABOUT
    }
}

The signal comes from a dll function. I attempt to port this principle into a framework in the next manner:

  1. I have a main again but this main gets the static instance of a class i1. This class has a member function "event_checking" doing the same piece of code above.

  2. I can access to this event_checking function through an instance i2 of an intermediate class so I decided to Wrap i1.event_checking with

    void eventCheckingWrapper(){
    i1.event_checking();
}

  3. Still in the main I spawn a thread on eventCheckingWrapper. So I am not interested in the thread returning as long as signals arrive. An example of this principle could be:

    std::thread t(&ClassName::eventCheckingWrapper, &i2);

The thread is running well but no signals are arriving such that the timeout is always reached and the thread starts over in its while loop.

How can I properly get this to work?

tricostume
  • 3
  • 4
  • The thread needs the handle from the DLL, it can then wait on the handle and call your event wrapper when signaled – Remy Lebeau Mar 27 '19 at 20:06
  • In both cases I get the handle from the dll. Just in one case I get it at main and in the other inside the event_checking function just before infinite while , in which the handle is waited for many times. – tricostume Mar 27 '19 at 20:18
  • Unless the DLL is thread-aware (unlikely), it shouldn't matter which thread obtains the handle. But, you could always make `main` obtain the handle first and then pass it to the thread, if needed. Waiting on a handle with `WaitForSingleObject()` can be done in any thread regardless of which thread obtains the handle. If your thread is not detecting a signal, then either the handle is not being signaled at all, or the handle state is being reset to unsignaled before the thread waits on it. – Remy Lebeau Mar 27 '19 at 20:26

1 Answers1

0

I solved the issue. So everything Remy Lebeau said was true. In the end the dll had a function to activate the reception of signals through the event handle that I had to call before. So in reality no signals were coming but just to be informative what I could confirm after this debugging experience was basically that "parent" threads need to be kept alive in Windows, winapi WaitForSingleObject() keeps the state of an event signaled if it has not been waited for and new re-setting an event does not change its state (remains signaled) as long as no thread has waited for it (after which it changes to unsignaled mode) so time issues do not arise. As a matter of fact, it should be checked if the events provided by 3d party software care about the thread in which it was created and if therefore there is no problem where the handle is retrieved. Thanks!

tricostume
  • 3
  • 4