max_execution_time always 0 on Windows

[Serveronet]

What happened?

max_execution_time in phpinfo() is always 0 on Windows.
As a result script times out with: Maximum execution time of 5 seconds exceeded.

The problem is on Windows only.
Steps to reproduce.

• Fetch windows zip
• Unzip
• Place index.php with <?php phpinfo();
• Start frankenphp with .\frankenphp.exe php-server
• Observe in phpinfo max_execution_time 0 0

Notes:
Setting max_execution_time through php.ini or Caddyfile makes no difference.
On linux works correctly with default and also setting have proper effect max_execution_time 30 30
v1.12.4

Build Type

Static binary

Worker Mode

No

Operating System

Windows

CPU Architecture

x86_64

PHP configuration

phpinfo() output

Without php.ini

Relevant log output

Relevant log output

[Serveronet]

AI findings for your discretion:

AI findings

Root Cause
In frankenphp.c:1446-1453, when ZEND_MAX_EXECUTION_TIMERS is not defined at compile time (always the case on Windows — it's a POSIX-only setitimer feature), FrankenPHP calls go_get_custom_php_ini(true) which unconditionally forces max_execution_time=0 and max_input_time=-1 (phpmainthread.go:194-197). This override takes precedence over ALL user configuration (php.ini, Caddyfile, WithPhpIni).

The comment claims "Timeouts are fundamentally broken with ZTS" referencing PHP bug #79464, but that bug is about setitimer(ITIMER_PROF) not being thread-safe — a POSIX-specific issue. PHP's Windows implementation uses CreateTimerQueueTimer() (in zend_execute_API.c), which correctly captures a pointer to the calling thread's executor globals at timer creation and sets vm_interrupt/timed_out atomically from a system thread-pool callback. This works correctly in ZTS mode.

Additionally, the worker-mode timeout management (zend_unset_timeout() before waiting, zend_set_timeout() for execution phase) was gated behind #ifdef ZEND_MAX_EXECUTION_TIMERS, which excluded Windows.

Changes Made
frankenphp.c — 4 locations changed #ifdef ZEND_MAX_EXECUTION_TIMERS to #if defined(ZEND_MAX_EXECUTION_TIMERS) || defined(PHP_WIN32):

Line 454: Worker request startup — input timeout setup
Line 687: Worker frankenphp_handle_request() — unset timeout before waiting for request
Line 700: Worker frankenphp_handle_request() — set execution timeout after request received
Line 1446: INI override — stop forcing max_execution_time=0 on Windows
phpmainthread.go — Updated comment to clarify Windows has working timeout support via CreateTimerQueueTimer.

Summary

This change fixes the Windows max_execution_time=0 bug by extending 4 preprocessor guards from #ifdef ZEND_MAX_EXECUTION_TIMERS to #if defined(ZEND_MAX_EXECUTION_TIMERS) || defined(PHP_WIN32). PHP's Windows CreateTimerQueueTimer-based timeout mechanism works correctly in ZTS mode, unlike the broken setitimer(ITIMER_PROF) on POSIX without ZEND_MAX_EXECUTION_TIMERS. All sub-agent tracks (security, performance, business logic, dead code, duplication) passed clean.

Issues Found

Severity	File:Line	Issue
SUGGESTION	frankenphp.c:1446	Silent behavioral change for existing Windows users — scripts that relied on the forced max_execution_time=0 will now honor the php.ini default of 30 seconds

Detailed Findings

• File: frankenphp.c:1446
• Confidence: High
• Problem: Windows users upgrading to this version will experience a behavioral change: scripts running longer than 30 seconds will now be killed by the PHP timeout. Previously, max_execution_time was forcibly set to 0 (unlimited), which was a bug but may have been relied upon. This is a correct fix but is a breaking change for Windows deployments with long-running scripts.
• Suggestion: This is the correct fix for the bug. The behavioral change is expected — it restores standard PHP timeout behavior on Windows. Users who need unlimited execution time can explicitly set max_execution_time = 0 in their php.ini. No code change needed; just be aware of the upgrade impact.

Recommendation

APPROVE — The fix is technically correct. Windows CreateTimerQueueTimer is thread-safe in ZTS mode, the timeout lifecycle (create/unset/set) is properly managed across all code paths, and all 4 preprocessor guards are applied consistently.