Where in Cocoa can I find an infinite loop??

Discussion in 'iOS Programming' started by pflau, Aug 29, 2010.

  1. pflau macrumors 6502

    Joined:
    Sep 17, 2007
    #1
    Hi. I have a function that needs to be called repeatedly for the entire duration of the program, is there an infinite loop in Cocoa that I can stick this function in? For instance, in Windows, I can write something like

    Code:
    LRESULT MyWindow::WindowProc(UINT message, WPARAM wParam, LPARAM lParam)
    {
          myFunction();
         // OnWndMsg does most of the work, except for DefWindowProc call
         LRESULT lResult = 0;
         if (!OnWndMsg(message, wParam, lParam, &lResult))
              lResult = DefWindowProc(message, wParam, lParam);
         return lResult;
    }
    
    and stick myFunction into the WindowProc.

    Basically, WindowProc is called by Windows in an infinite loop to check and dispatch messages. I override this function so it would call my function as well. This way I save myself a thread and I don't need to deal with asynchronous access to my data.

    I wonder if there is anything similar in Cocoa. Thanks.
     
  2. ianray macrumors 6502

    Joined:
    Jun 22, 2010
    Location:
    @
    #2
    Your requirements are satisfied by using a repeating timer.
     
  3. pflau thread starter macrumors 6502

    Joined:
    Sep 17, 2007
    #3
    That is certainly true. However, the mandatory timer interval is not ideal when you're in a high volume, low latency environment where your application must loop as fast as it can even at the expense of CPU consumption. Think about high frequency trading and realtime market data.
     
  4. ianray macrumors 6502

    Joined:
    Jun 22, 2010
    Location:
    @
    #4
    So this is actually an I/O bound problem.

    • Use asynchronous network APIs and kick off an initial request
    • when new data arrives kick off a new request
    • process that data while the new request is active
     
  5. pflau thread starter macrumors 6502

    Joined:
    Sep 17, 2007
    #5
    It is not an I/O bound problem. There is no requirement that all input must be process. There IS the requirement that the process MUST take place as fast as possible. So it is a CPU bound problem - using an infinite loop is thus the best way to take up as much CPU time as possible.
     
  6. robbieduncan Moderator emeritus

    robbieduncan

    Joined:
    Jul 24, 2002
    Location:
    London
    #6
    The NSRunLoop is similar in idea to your WindowProc. An NSTimer scheduled at a very short repeat will actually get called every time through the run loop (which is an infinite loop to the point the app ends). Or to ensure your method is called every time through the loop call performSelector:target:argument:eek:rder:modes: on the current run loop and call the same at the end of the method to schedule again for the next time through the loop.
     
  7. pflau thread starter macrumors 6502

    Joined:
    Sep 17, 2007
    #7
    I wonder how small I can make the timer interval value.. like 0.0001 or some rediculous number. Anyway, calling NSRunLoop's performSelector repeatedly is definitely clever.. I did not considered that when Iooked at it initially.
     
  8. robbieduncan Moderator emeritus

    robbieduncan

    Joined:
    Jul 24, 2002
    Location:
    London
    #8
    Just consider how long the method you schedule takes to run each time: if you block the main runloop the UI will freeze...
     
  9. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #9
    Maybe use a CFRunLoopObserver. Google it. Read its reference docs. Then look up CFRunLoop and NSRunLoop's getCFRunLoop method.

    If you're really trying to write a high frequency trading app for iOS, my guess is it's probably doomed. You're unavoidably at the mercy of wifi latencies and other protocol delays, in addition to any kernel scheduling delays, or being pre-empted due to display or audio needs that your app has no control over. Neither iOS, nor Mac OS X, nor Windows is a real-time OS.

    EDIT:
    No matter what you eventually use, you really need to test it on a device, and under adverse conditions. For example, playing audio in the background will take resources, and audio processing effectively has higher priority. Since your app can't control whether the user is playing iTunes (or other audio, or other apps) at the same time, you have to accept whatever the OS does behind your back.
     
  10. pflau thread starter macrumors 6502

    Joined:
    Sep 17, 2007
    #10
    No I am not really writing a high frequency trading app.. that was just an analogy. My initial reference to the WinProc procedure was how clean the implementation was. If we are to get into using an observer and all that, then it is starting to negate the benefit of keeping everything in the same thread and I might as well create another thread and do the semaphore/mutex thing.
     
  11. ianray macrumors 6502

    Joined:
    Jun 22, 2010
    Location:
    @
    #11
    Why switch to the (somewhat more costly) thread-based approach, when you can use NSRunLoop's performSelector?

    This is, in fact, essentially the same as hooking WindowProc and calling PostMessage, right?
     
  12. pflau thread starter macrumors 6502

    Joined:
    Sep 17, 2007
    #12
    Yes I agree that would be the way to go.
     
  13. kainjow Moderator emeritus

    kainjow

    Joined:
    Jun 15, 2000
    #13
    You could consider using CFRunLoopTimer directly and avoid Objective-C altogether...
     
  14. Luke Redpath macrumors 6502a

    Joined:
    Nov 9, 2007
    Location:
    Colchester, UK
    #14
    If you're trying to update the UI, there is very little point in scheduling something to happen faster than the main runloop as the screen will not redraw faster than the main runloop anyway.
     
  15. Sykte macrumors regular

    Joined:
    Aug 26, 2010
    #15

    Have you tried standing outside in Apple's parking lot.


    Sorry I had to.
     
  16. jared_kipe macrumors 68030

    jared_kipe

    Joined:
    Dec 8, 2003
    Location:
    Seattle
    #16
    I smell premature optimization. Why not start off with a repeating timer once every second and see if you can even process the data fast enough.

    Maybe I'm not thinking outside the box enough, but I fail to see what kind of "realtime market data" could possibly be processed or needed every 0.0001seconds.
     
  17. pflau thread starter macrumors 6502

    Joined:
    Sep 17, 2007
    #17
    Precisely my point.
     
  18. pflau thread starter macrumors 6502

    Joined:
    Sep 17, 2007
    #18
    I said Cocoa, not Cupertino.
     
  19. Luke Redpath macrumors 6502a

    Joined:
    Nov 9, 2007
    Location:
    Colchester, UK
    #19
    So what is the problem?
     
  20. pflau thread starter macrumors 6502

    Joined:
    Sep 17, 2007
    #20
    The problem was to find an infinite loop. One of the solutions suggested was to use a timer, and I said it is not ideal because it mandates a timer interval. Doing so makes an assumption about how fast the GUI can update. A real infinite loop on the other hand guarantees that it provides data as fast as the GUI can handle.
     
  21. Cromulent macrumors 603

    Cromulent

    Joined:
    Oct 2, 2006
    Location:
    The Land of Hope and Glory
    #21
    Considering the majority of stock market trading is automatic (at least it used to be) then, yes. Milliseconds are important.
     

Share This Page