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. .NET (Core and Framework)
  4. Equivalent to WSAWaitForMultipleEvents in .NET

Equivalent to WSAWaitForMultipleEvents in .NET

Scheduled Pinned Locked Moved .NET (Core and Framework)
csharpc++designarchitecture
6 Posts 3 Posters 0 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.
  • L Offline
    L Offline
    lemur
    wrote on last edited by
    #1

    Hi, I've got some C++ code to convert to C# and I'd prefer the C# to be as similar in design to the legacy code as possible (not my original design). Currently, I'm not having much luck finding an equivalent to WSAWaitForMultipleEvents() that lives in the managed world. Also, the current architecture doesn't allow for a higher-level repackaging with a C++/CLI. Could anyone point me towards it if I'm just not seeing it in MSDN after staring at the screen for too long, or alternatively put me out my misery so I know I've just got to go with a rethink and rework and new time estimate. Thanks v. much in advance, Kev

    S M 2 Replies Last reply
    0
    • L lemur

      Hi, I've got some C++ code to convert to C# and I'd prefer the C# to be as similar in design to the legacy code as possible (not my original design). Currently, I'm not having much luck finding an equivalent to WSAWaitForMultipleEvents() that lives in the managed world. Also, the current architecture doesn't allow for a higher-level repackaging with a C++/CLI. Could anyone point me towards it if I'm just not seeing it in MSDN after staring at the screen for too long, or alternatively put me out my misery so I know I've just got to go with a rethink and rework and new time estimate. Thanks v. much in advance, Kev

      S Offline
      S Offline
      Super Lloyd
      wrote on last edited by
      #2

      How about something like Socket.Select()[^]?

      A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.

      L 1 Reply Last reply
      0
      • S Super Lloyd

        How about something like Socket.Select()[^]?

        A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.

        L Offline
        L Offline
        lemur
        wrote on last edited by
        #3

        You gave me a brief glimmer of hope there that I hadn't read the docs properly and that it was something that obvious, but no. :( Socket.Select() does only work with sockets. I've given up now to be honest. I'll go with Socket.Select() with an internal control socket that, when data is read from it, is the signal to close down the main socket. Not ideal, but it's a close enough workaround that it's still clear what's happening in the ported code even though the events have been swapped for sockets. As being close and preserving the overall code structure is what I've been asked to do, it's good enough. Thanks very much for the response anyway! Kev

        S 1 Reply Last reply
        0
        • L lemur

          You gave me a brief glimmer of hope there that I hadn't read the docs properly and that it was something that obvious, but no. :( Socket.Select() does only work with sockets. I've given up now to be honest. I'll go with Socket.Select() with an internal control socket that, when data is read from it, is the signal to close down the main socket. Not ideal, but it's a close enough workaround that it's still clear what's happening in the ported code even though the events have been swapped for sockets. As being close and preserving the overall code structure is what I've been asked to do, it's good enough. Thanks very much for the response anyway! Kev

          S Offline
          S Offline
          Super Lloyd
          wrote on last edited by
          #4

          In fact I don't know where this idea to look at Socket.Select() comes from. When I read your post and the documentation again, nothing mention socket!?! :confused: Anyway, how about: Semaphore[^], or multiple call to ThreadPool.RegisterWaitForSingleObject[^]?

          A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.

          L 1 Reply Last reply
          0
          • L lemur

            Hi, I've got some C++ code to convert to C# and I'd prefer the C# to be as similar in design to the legacy code as possible (not my original design). Currently, I'm not having much luck finding an equivalent to WSAWaitForMultipleEvents() that lives in the managed world. Also, the current architecture doesn't allow for a higher-level repackaging with a C++/CLI. Could anyone point me towards it if I'm just not seeing it in MSDN after staring at the screen for too long, or alternatively put me out my misery so I know I've just got to go with a rethink and rework and new time estimate. Thanks v. much in advance, Kev

            M Offline
            M Offline
            Mark Salsbery
            wrote on last edited by
            #5

            lemur wrote:

            an equivalent to WSAWaitForMultipleEvents() that lives in the managed world

            On Windows, WSAWaitForMultipleEvents is the same as WaitForMultipleObjectsEx(). WaitForMultipleObjectsEx() in .NET is WaitHandle.WaitAny().

            Mark Salsbery Microsoft MVP - Visual C++ :java:

            1 Reply Last reply
            0
            • S Super Lloyd

              In fact I don't know where this idea to look at Socket.Select() comes from. When I read your post and the documentation again, nothing mention socket!?! :confused: Anyway, how about: Semaphore[^], or multiple call to ThreadPool.RegisterWaitForSingleObject[^]?

              A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.

              L Offline
              L Offline
              lemur
              wrote on last edited by
              #6

              You're closer with Socket.Select rather than the others which work on WaitHandles. I'll look into getting a WaitHandle-based object associated with a socket so I could use the regular WaitForMultipleObjects but the client's happy with the socket-workaround I told in last mail. Thanks again. K

              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