Reduce busy-waiting CPU load in waitEvents()

[hiddenalpha]

The waitEvents() implementation on non-windows systems usually returns immediately. This is unfortunate for the callers which want to await events in an infinite-loop. As doing so would burn lot of CPU time.

For example: Code in LinuxEventThread.run() (in SerialPort.java) calls us in an infinite-loop. As a work-around, it uses a (very) small sleep, to not utilize a full CPU core all the time. But still, this permanently wastes a lot of CPU cycles (that many, that it is a problem in our production use-case). The win32 code uses OVERLAPPED structs and WaitSingleObject() which already provide that kind of "wait" mechanism.

Edit: Unfortunately I've no idea how to fix macOS CICD build :(

[pietrygamat]

Unfortunately I've no idea how to fix macOS CICD build :(

The macos-latest runner seems to evolve faster that this project can handle ;P.
The issue seems to be with the older SDK version the pipeline manually downloads and forces:

[MT] DVTSDK: Skipped SDK /Applications/Xcode_16.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk; its version (10.9) is below required minimum (14.0) for the macosx platform.

We can fix the build by either using older macos runner (macos-14 instead of macos-latest) or bumping macos-deployment-target to 14.0+ (simplify the pipeline too). @tresf, you may want to select the right approach that also avoids pitfals such as #187 .

[tresf]

We can fix the build by either using older macos runner (macos-14 instead of macos-latest) or bumping macos-deployment-target to 14.0+ (simplify the pipeline too). @tresf, you may want to select the right approach that also avoids pitfals such as #187 .

@pietrygamat thanks for digging into this... I have to admit each time I revisit this my memory is more and more foggy what we can and can't do with the older SDKs.

I bump into this a lot with another project and this is what we do over there...

  macos:
    strategy:
      fail-fast: false
      matrix:
        arch: [ x86_64, arm64 ]
        include:
          - arch: x86_64
            os: macos-15-intel
            xcode: "16.4"
          - arch: arm64
            os: macos-15
            xcode: "16.4"

... specifically though, we leverage an environment variable MACOSX_DEPLOYMENT_TARGET. Although that project has dependencies that influence this value, to the best of my knowledge, JSSC doesn't, so we should be able to leverage this to target any OS we wish. Back in the day I thought that this was a false-promise and that the SDK variable was a joke, but the other project proved my suspicions false... Quoting:

@Mr-Emoticon63 are you on Intel or Apple Silicon?

Finally, we have conversation in here. Also, I’m using Intel because my laptop is from 2015.

Thanks, I asked because of the following statement early into the thread...

Sadly, I don't believe this does anything useful because the Homebrew dependencies are pre-compiled for the target macOS version, which is currently set to macos-13 per:

This statement is slightly misleading... My vague memory of this all was that the SDK level needs to be compatible with the current OS level and that macOS generally provides backwards compatibility for two versions. (Prior to macOS 11, the versions were in point format, so "two versions" changes definitions slightly if we're discussing older macOS versions)... however your feedback in combination with @barracuda156's words make me less sure of this...

I have seen too many instances where arbitrarily high hardcoded deployment target

What's puzzling to me is whether or not a binary produced using e.g. 15.2 can be RUN on e.g. minos 11.0 at all (or in the case of Intel 14.2 vs. 10.13). Regardless, my branch here just mimics what Homebrew does by copying the same exact minos value into our build system. My statements about this "not working" were clearly incorrect based on your testing.

This is to say there's some SDK backwards-compatibility that I'm clearly missing, but this explains why @messmerd's original PR fixes your issue. Here's the Intel download from my PR: (this link will eventually expire) if you can test it out on your machine. Meanwhile, I'm trying to setup a macOS 12 VM to test the same for Apple Silicon.

That's a lot to say that MACOSX_DEPLOYMENT_TARGET seems to work well as long as we don't compile against any APIs that are specific to newer macOS versions (which I don't think we do).

Copying the other project's strategy it does still use a hard-coded runner version macos-15[-intel] which I think is sane considering macos-14 will start throwing deprecation warnings next month.

• [macOS] The macOS 14 Sonoma based runner images will begin deprecation on July 6th and will be fully unsupported by November 2nd for GitHub Actions and Azure DevOps actions/runner-images#13518

Edit: Whoops, sorry for the copy/paste tags above.

[hiddenalpha]

... either using older macos runner (macos-14 instead of macos-latest) ...
... bumping macos-deployment-target to 14.0+ ...
... I bump into this a lot with another project and this is what we do over there: ...
... we should be able to leverage this to target any OS we wish. ...
... Back in the day I thought that this was a false-promise and that the SDK variable was a joke, but the other project proved my suspicions false ...

I did not yet understand the comments about MacOS. So what should jssc do? I'll give one of the suggestions a try 🙂

Edit 1: I could not find anything that would look like 14.0+-ish in MacOSX-SDKs. Will try another suggestion then.

[tresf]

So what should jssc do

Your PR can just use an old runner, even if it's EOL in a month. @pietrygamat and I will have to look for a more permanent solution, but it doesn't necessarily need to be fixed here.

[tresf]

I tested the baseline functionality for regressions, none were found. I did not test the new timeout feature, just regression tested the old feature.

Since Windows already behaved this way, there's a part of me that wants this to just be the new default with a sane value to bring better parity however the code comments suggest that there are conditions where this is undesired, so I'm fine with it as-is.

I do like the current implementation of setting this globally so all connections behave the same way, so no objections here. Perhaps the last enhancement I would request is to provide a recommended value for others experiencing this issue (e.g. 2ms?), since the implementation may be otherwise lost upon the casual onlooker.