Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. WaitForSingleObject not signaled

WaitForSingleObject not signaled

Scheduled Pinned Locked Moved C / C++ / MFC
help
6 Posts 2 Posters 1 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • F Offline
    F Offline
    ForNow
    wrote on last edited by
    #1

    Hi I have a CAsynSocket as a member of a CwinThread (having each socket connection in its own thread) The program is acting as Client When I do a connect everything goes as a planned I get the OnConnect Notification and OnSend (though they always come in the context of the Main Thread). Since I would like to know when this happens I Wait on a CEvent. The CEvent is a member of the CwinThread. The only problem is that when I do the WaitForSingleObject nothing happens (as far as notification OnSend OnConnect)

    L F 2 Replies Last reply
    0
    • F ForNow

      Hi I have a CAsynSocket as a member of a CwinThread (having each socket connection in its own thread) The program is acting as Client When I do a connect everything goes as a planned I get the OnConnect Notification and OnSend (though they always come in the context of the Main Thread). Since I would like to know when this happens I Wait on a CEvent. The CEvent is a member of the CwinThread. The only problem is that when I do the WaitForSingleObject nothing happens (as far as notification OnSend OnConnect)

      L Offline
      L Offline
      leon de boer
      wrote on last edited by
      #2

      WaitForSingleObject will suspend the entire thread it's running in :-) So your OnSend and OnConnect code better not be on that thread or they will never be called which is what you are saying !!!!!!! It's called a deadlock the only thing that can release the WaitForSingleObject is an event that will never be sent because the detecting code to create the event will never run. Sounds to me like you need to get out a pen and paper again and work out the logic of the threads.

      In vino veritas

      F 1 Reply Last reply
      0
      • L leon de boer

        WaitForSingleObject will suspend the entire thread it's running in :-) So your OnSend and OnConnect code better not be on that thread or they will never be called which is what you are saying !!!!!!! It's called a deadlock the only thing that can release the WaitForSingleObject is an event that will never be sent because the detecting code to create the event will never run. Sounds to me like you need to get out a pen and paper again and work out the logic of the threads.

        In vino veritas

        F Offline
        F Offline
        ForNow
        wrote on last edited by
        #3

        Hi Thanks I think that in any scenario (CAsynSocket being a member of a CWinThread) socket notification always happen in the context of the main thread

        1 Reply Last reply
        0
        • F ForNow

          Hi I have a CAsynSocket as a member of a CwinThread (having each socket connection in its own thread) The program is acting as Client When I do a connect everything goes as a planned I get the OnConnect Notification and OnSend (though they always come in the context of the Main Thread). Since I would like to know when this happens I Wait on a CEvent. The CEvent is a member of the CwinThread. The only problem is that when I do the WaitForSingleObject nothing happens (as far as notification OnSend OnConnect)

          F Offline
          F Offline
          ForNow
          wrote on last edited by
          #4

          First off let me say I am by trade a MainFrame Programer In Z/os you can issue a wait anywhere in a task or thread and it will suspend that unit of work or program. In MVS many programs comprise a task The program information is saved in a RB block But the task or Thread doesn't stop I understand this is not the case in Windows

          L 1 Reply Last reply
          0
          • F ForNow

            First off let me say I am by trade a MainFrame Programer In Z/os you can issue a wait anywhere in a task or thread and it will suspend that unit of work or program. In MVS many programs comprise a task The program information is saved in a RB block But the task or Thread doesn't stop I understand this is not the case in Windows

            L Offline
            L Offline
            leon de boer
            wrote on last edited by
            #5

            You need to understand this isn't even about Windows you are using a framework and you need to understand the framework. Windows if you were dealing with the API can do some very different things and in your case the framework determines the behaviour because it was designed with a concept in mind. Since you seem to need proof the thread is blocked make the wait 10 seconds and look for the timeout

            DWORD Ret=WaitForSingleObject(yourEvent, 10000);
            if (Ret==WAIT_TIMEOUT)
            {
            TRACE("*** Houston we have a Timeout ... Thread blocked LdB right ***\n");
            }

            If I am right you will get that message 10 seconds later .. so easy to test with 3 lines of code The solution is play nicely with CAsynSocket or go direct down onto the Windows API and do the socket work yourself. I don't doubt your programming ability just your understanding of the Framework.

            In vino veritas

            F 1 Reply Last reply
            0
            • L leon de boer

              You need to understand this isn't even about Windows you are using a framework and you need to understand the framework. Windows if you were dealing with the API can do some very different things and in your case the framework determines the behaviour because it was designed with a concept in mind. Since you seem to need proof the thread is blocked make the wait 10 seconds and look for the timeout

              DWORD Ret=WaitForSingleObject(yourEvent, 10000);
              if (Ret==WAIT_TIMEOUT)
              {
              TRACE("*** Houston we have a Timeout ... Thread blocked LdB right ***\n");
              }

              If I am right you will get that message 10 seconds later .. so easy to test with 3 lines of code The solution is play nicely with CAsynSocket or go direct down onto the Windows API and do the socket work yourself. I don't doubt your programming ability just your understanding of the Framework.

              In vino veritas

              F Offline
              F Offline
              ForNow
              wrote on last edited by
              #6

              I don't need proof I know you are right thanks for explaining :)

              1 Reply Last reply
              0
              Reply
              • Reply as topic
              Log in to reply
              • Oldest to Newest
              • Newest to Oldest
              • Most Votes


              • Login

              • Don't have an account? Register

              • Login or register to search.
              • First post
                Last post
              0
              • Categories
              • Recent
              • Tags
              • Popular
              • World
              • Users
              • Groups