Re: [PATCH] fsmonitor: eliminate call to deprecated FSEventStream function

> 
> On Fri, Dec 02 2022, Jeff Hostetler via GitGitGadget wrote:
> 
>> From: Jeff Hostetler <jeffhostetler@github.com>
>>
>> Replace the call to `FSEventStreamScheduleWithRunLoop()` function with
>> the suggested `FSEventStreamSetDispatchQueue()` function.
>>
>> The MacOS version of the builtin FSMonitor feature uses the
>> `FSEventStreamScheduleWithRunLoop()` function to drive the event loop
>> and process FSEvents from the system.  This routine has now been
>> deprecated by Apple.  The MacOS 13 (Ventana) compiler tool chain now
>> generates a warning when compiling calls to this function.  In
>> DEVELOPER=1 mode, this now causes a compile error.
>>
>> The `FSEventStreamSetDispatchQueue()` function is conceptually similar
>> and is the suggested replacement.  However, there are some subtle
>> thread-related differences.
>>
>> Previously, the event stream would be processed by the
>> `fsm_listen__loop()` thread while it was in the `CFRunLoopRun()`
>> method.  (Conceptually, this was a blocking call on the lifetime of
>> the event stream where our thread drove the event loop and individual
>> events were handled by the `fsevent_callback()`.)
>>
>> With the change, a "dispatch queue" is created and FSEvents will be
>> processed by a hidden queue-related thread (that calls the
>> `fsevent_callback()` on our behalf).  Our `fsm_listen__loop()` thread
>> maintains the original blocking model by waiting on a mutex/condition
>> variable pair while the hidden thread does all of the work.
> 
> I just skimmed the code change and didn't see anything out of place, but
> one thing that's missing about this explanation is:
> 
> Ok, it's deprecated, but when was it introduced? I.e. we now presumably
> have a hard dependency on a newer API released with a newer version of
> OSX?
> 
> Is it OK that we're going to throw compilation errors on older versions
> that don't have it? What version is that? Is that older or newer than
> our oldest supported OSX version in general, or is the plan to support
> older OSX, but those users would need to compile without fsmonitor?
> 
> Depending on the answers to the above (hopefully in a re-rolled commit
> message): Should we patch the bit in config.mak.uname where we do the
> OSX version detection? I.e. if we're deprecating an older version anyone
> still on it would be much better off with a straight-up "$(error)" from
> the Makefile, rather than running into a compilation error, only to find
> that we've stopped supporting that older version.