auto-update-0.2.5 - a warning

[alaendle]

With the update to 0.2.5 we've seen some errors like

 test: GHC.Internal.Event.Thread.getSystemTimerManager: the TimerManager requires linking against the threaded runtime
           CallStack (from HasCallStack):
             error, called at libraries/ghc-internal/src/GHC/Internal/Event/Thread.hs:290:13 in ghc-internal:GHC.Internal.Event.Thread
           HasCallStack backtrace:
             collectBacktraces, called at libraries/ghc-internal/src/GHC/Internal/Exception.hs:92:13 in ghc-internal:GHC.Internal.Exception
             toExceptionWithBacktrace, called at libraries/ghc-internal/src/GHC/Internal/IO.hs:260:11 in ghc-internal:GHC.Internal.IO
             throwIO, called at libraries/ghc-internal/src/GHC/Internal/Control/Exception/Base.hs:195:43 in ghc-internal:GHC.Internal.Control.Exception.Base

during stackage test-suite execution - however not directly on the auto-update tests, but on dependent projects like http-reverse-proxy - unfortunately we lack a clear reproduction, for now we've noticed the problem only on the stackage server (also only in complete build cycles, running tests of a single package succeed) - also I failed to reproduce things like that on my local machine. But at least the problems occur consistent and on lts and nightly, so with ghc-9.8.4 and ghc-9.10.1. Also I believe that this might be the root cause for other problems that start to occur the same time like:

(ConnectionFailure Network.Socket.connect: <socket: 6>: unsupported operation (Cannot assign requested address))
           HasCallStack backtrace:
             collectBacktraces, called at libraries/ghc-internal/src/GHC/Internal/Exception.hs:92:13 in ghc-internal:GHC.Internal.Exception
             toExceptionWithBacktrace, called at libraries/ghc-internal/src/GHC/Internal/IO.hs:260:11 in ghc-internal:GHC.Internal.IO
             throwIO, called at ./Network/HTTP/Client/Core.hs:214:29 in http-client-0.7.17-IncG67QVij97hnYFCn3f1x:Network.HTTP.Client.Core

For now we "resolved" the problem by expecting all affected test-suites to fail (commercialhaskell/stackage@ef39034).

Sorry that we couldn't provide a clearer picture of the problem.

[alaendle]

If this is really true that auto-update-0.2.5 requires the threaded runtime to function properly, this would be a big breaking change since lot of test suites indirectly depend on auto-update that just use the default (non-threaded) runtime.

[alaendle]

@kazu-yamamoto, @khibino Maybe rethink #1018?

[Vlix]

Very unfortunate that getSystemTimerManager has no documentation.

And that it forces fromMaybe error essentially, when it could have also just returned Maybe TimerManager 🤔

@kazu-yamamoto Would it be an idea to:

• try a getSystemTimerManager call in the Control.AutoUpdate.Event.mkAutoUpdate* functions
• make it discard the result, but return True
• Surround it with a catch to catch the ErrorCall exception, and return False
• depending on that result use the Thread or Event style?