macOS continuous polling

[scott455]

if this code is running inside a macos objetive-c library code, is there anything to add the " //go next iteration" section?. In windows, some add peekmessage,etc. to do events. does the same thing needed in MacOS?.

while (...)
{
 i = i +1;
  a = checkbf
  if (a)
  {
      //someting
      break
  }
  else
  {
  //go next iteration
  }
  if (i > 1000)
    break;
}

 

[casperes1996]

I think there's some context missing here. What is the goal. Why do you think the code will not be executed if a is 0? Why is that whole if (I > 1000) bit not just part of the while condition?
Technical questions benefit from being detailed and explicit

 

[scott455]

I think there's some context missing here. What is the goal. Why do you think the code will not be executed if a is 0? Why is that whole if (I > 1000) bit not just part of the while condition?
Technical questions benefit from being detailed and explicit

Sorry if my question is weird. Ok, this is for most part a sudo code, not really a complete code. the I > 1000 could be part of the while condition. the line "//go next iteration" is empty just to go to the next polling iteration. In windows could cause UI freezes if loop is large. In the macos objective-c, could be something added to that line to improve things?. Windows and Macos do not process message queues the same, maybe it is ok in macos. Need to get some possible inputs. Will verify it.

 

[casperes1996]

Sorry if my question is weird. Ok, this is for most part a sudo code, not really a complete code. the I > 1000 could be part of the while condition. the line "//go next iteration" is empty just to go to the next polling iteration. In windows could cause UI freezes if loop is large. In the macos objective-c, could be something added to that line to improve things?. Windows and Macos do not process message queues the same, maybe it is ok in macos. Need to get some possible inputs. Will verify it.

Right so you're essentially just asking about UI responsiveness relative to thread scheduling?
Well, any work scheduled on the main thread will pause UI updates because the UI is always updated on the main thread or in Swift's model, the MainActor. So if this is running on the main thread it will block the UI, including calling blocking functions. You'll want to move that to another Thread or a concurrent DispatchQueue or something to avoid that or use non-blocking calls with callbacks which effectively do the same thing.