Re: AppKit, libdispatch and 100% CPU

[Tom Sheffler]

> Date: Tue, 22 Aug 2023 08:37:24 -0700
> From: Tom Sheffler <tom.sheffler@gmail.com>
> To: discuss-gnustep@gnu.org
> Subject: AppKit, libdispatch and 100% CPU
> Message-ID:
>       <CAMBtMcui299U1iF--r+5jrcgjSv13tGzQxxZ4Vf39dLce_k9zQ@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> ...

> In an app that creates a window with AppKit and calls
> dispatch_async(dispatch_get_main_queue, ...) I am seeing the CPU spike to
> 100% when nothing is happening.  I first noticed in a small program that
> had a background queue that wanted to update the display.  But I have
> managed to illustrate the issue in a very simple program here:



A followup to my previous post about a use of AppKit with dispatch_async and 
observing 100% CPU use.  I have an easy workaround, but thought I would report 
what I learned along the way.

The use case is the situation when an operation on the non-main queue
wishes to update a GUI element.  The canonical way to do this with dispatch is

    dispatch_async(dispatch_get_main_queue(), ^{
      OpThatModifiesAppKitGuiWidgets();
      });

However, when using this with [NSApp run], after the first call to
dispatch_async to the main queue, the CPU goes to 100%.  If the call
doesn't happen at first, the CPU remains low, but then rises after the
first call.

    dispatch_after(5.0 SECONDS, non_main_queue, ^{
      dispatch_async(dispatch_get_main_queue, ^{
        OpThatModifiesAppKitGuiWidgets();
        });
      });

The CPU wouldn't go to 100% until after 5 seconds.

A straightforward way to fix this is to use performSelectorOnMainThread: 
instead of a dispatch to the main queue.

    [self performSelectorOnMainThread:@selector(theGuiOp:)
                   withObject:self
                    waitUntilDone:NO];

It's easy enough to write something like performBlockOnMainThread: so that the 
code
above becomes something like this

    [self performBlockOnMainThread:^{
      OpThatModifiesAppKitGuiWidgets();
      });

and then I can have blocks and all is fine.  The app runs well and the
CPU usage is low.  Use of non-main dispatch queues for background
operations is fine too.

What do I think is happenening?

Inside NSSRunLoop, there are two calls to dispatch internals

  _dispatch_get_main_queue_handle_4CF()
  _dispatch_main_queue_callback_4CF()

that give a handle to wait on and the function to run when its ready.
I'm no expert in RunLoop internals, but it seems that after the first
dispatch_async(main_queue()) the handle is always ready for reading
and some sort of busy-wait is happening.  Even when I have not
scheduled future events on the main_queue, it is woken up repeatedly.

-T