Rebuild listening sockets on foreground when not suspending in background - #19
Merged
Conversation
…ound With GCDWebServerOption_AutomaticallySuspendInBackground = NO the server keeps serving in the background instead of stopping, but iOS can still tear down its listening sockets once the process is actually suspended (e.g. the device is locked for a while). Nothing rebuilt them on resume, so the server silently stopped accepting connections even though it still looked started (swisspol/GCDWebServer#292). In that mode, observe UIApplicationWillEnterForeground and, if we were running, rebuild the listening sockets via the existing _stop/_start path. That notification only fires on a real background->foreground transition — exactly when a socket may have been reclaimed — so there is no churn on ordinary activation. _start reuses the previously assigned port, so client URLs stay valid, and because _stop only cancels the listening sources, already-accepted connections (in-flight uploads, open SSE streams) are unaffected. Verified headlessly (macOS, driving the same _stop/_start the handler uses): the port stays stable, new connections are accepted afterwards, and a long- lived SSE stream keeps delivering across the refresh. iOS/tvOS compile the handler. The actual "iOS reclaimed the socket" trigger can only be confirmed on-device.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
With GCDWebServerOption_AutomaticallySuspendInBackground = NO the server keeps serving in the background instead of stopping, but iOS can still tear down its listening sockets once the process is actually suspended (e.g. the device is locked for a while). Nothing rebuilt them on resume, so the server silently stopped accepting connections even though it still looked started (swisspol/GCDWebServer#292).
In that mode, observe UIApplicationWillEnterForeground and, if we were running, rebuild the listening sockets via the existing _stop/_start path. That notification only fires on a real background->foreground transition — exactly when a socket may have been reclaimed — so there is no churn on ordinary activation. _start reuses the previously assigned port, so client URLs stay valid, and because _stop only cancels the listening sources, already-accepted connections (in-flight uploads, open SSE streams) are unaffected.
Verified headlessly (macOS, driving the same _stop/_start the handler uses): the port stays stable, new connections are accepted afterwards, and a long- lived SSE stream keeps delivering across the refresh. iOS/tvOS compile the handler. The actual "iOS reclaimed the socket" trigger can only be confirmed on-device.