This issue has been noticed by at least someone before, e.g. Gerbil's getting started page says "./configure […] --enable-poll # For Linux and BSD; don't use this on macOS". [1]

I'll now pass some references on this topic:

• Apple's poll() man page in the latest version today (March 2020) says "BUGS: The poll() system call currently does not support devices.". (Not sure exactly what "devices" is here however from how Gambit reacts we can reliably deduce that Gambit's use of the console on Mac OS X does count as a "device" in this definition, unless of course poll() would have even more bugs that are not listed in this page.) [2]

• Apple's poll() has a really ugly history: until before Mac OS 10.12.2 (released Dec 2016), it always returned immediately. [3]

  For that old bug, I see at least two test scripts available, [3] and [4], the first one just uses a timeout, and the second one poll():s a pipe. The tests appear to be time-dependent.

Now to the parts I'm not clear about and where I guess some further steps are needed:

• Make a minimal reproduction script in C:

  I don't have a Mac OS installation to test on. Someone else who does, told me that poll() to the STDIN FD does work as expected, meaning the Gambit CPU hog bug on Mac OS X is not tested for that route (if the test outcome is correct).

  We should figure out which FD or device is the console "device" that still today maces Mac OS' poll() return immediately.

• Make Gambit make a debug print-out to get confirmed exactly how poll() fails:

  Just for completeness I'd love to know which return value poll() gives Gambit on Mac OS X right now, and also exactly which FD Gambit polls for. This is specifically with a fresh "gsi" with default IO settings, that is waiting for console input only.

• Isolate the issue in Gambit:

  We should do some alternative testing in Gambit where Gambit is not poll():ing the console, to get validated that for Gambit it's the console specifically that poll() doesn't work for i.e. for network descriptors and files it does what it should.

• Guess about how the solution should look:

  I guess the solution is that Gambit's ./configure on Mac OS X should ignore --enable-poll .

  If anyone likes to compile binaries for all platforms including Mac OS X that will never poll() the console, maybe those guys should do their |compile-file| with the C define correspondent of --enable-poll, that should be something like "-DENABLE_POLL", need to check.

So preliminarily it looks to me like that the latest version of Mac OS X does have a bug in poll(), and presuming this is correct, it's a great shame that Apple is forcing its whole ecosystem into ancient select() with all its constraints, quite incredible really.

I'll participate in just a bit more testing of this bug per above later. The CPU hogging is enough to turn on the fan on a Mac laptop, making it nicer to have the Gambit REPL not run than run, that is a really unnecessary annoyance.

@feeley what do you think & is a good solution.

(@vyzo after this is fixed the "# For Linux and BSD; don't use this on macOS" precaution in Gerbil should not apply anymore. That is also nice as special Gambit configure arguments for Mac OS X is an unnecessary asymmetry.)

Thanks!

[1] https://github.com/vyzo/gerbil/blob/bb287c5840fcb747c1047d8ff82c0977d8f9ca77/doc/guide/getting-started.md

[2] https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/poll.2.html

[3] https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/

[4] https://stackoverflow.com/questions/591826/it-really-looks-like-os-x-has-a-bug-when-using-poll-on-a-named-pipe-fifo