[reward] fix: restore timeout in math_verify via ProcessPoolExecutor

[MaxwellJryao]

What does this PR do?

Follow-up to #5635. That PR fixed the signal.alarm() crash by disabling all timeouts (parsing_timeout=None, timeout_seconds=None). However, this causes the reward worker to hang indefinitely on adversarial or complex model outputs that trigger pathological parsing in math_verify.

This PR restores timeout protection by running math_verify in a subprocess via ProcessPoolExecutor, where signal.alarm() works normally (each subprocess has its own main thread). An outer future.result(timeout=30) provides a fallback guarantee.

Checklist Before Starting

• Search for similar PRs. Paste at least one query link here:
  https://github.com/verl-project/verl/pulls?q=is%3Apr+math_verify+signal
• Format the PR title as [{modules}] {type}: {description}

Test

Validated on Qwen2.5-3B-Instruct GRPO training with MATH500 val set on 4-node cluster:

• Before fix ([reward] fix: disable signal.alarm() in math_verify to fix silent scoring failure in Ray workers #5635 with parsing_timeout=None): Training hangs at step 2 — a single math_verify call blocks the RewardLoopWorker indefinitely. All GPUs idle.
• After fix: Training runs continuously. Problematic inputs are killed after 30s timeout and scored as 0.

API and Usage Example

No API changes — same compute_score(model_output, ground_truth) signature. New optional timeout parameter (default 30s).

Design & Code Changes

1. Run parse() + verify() in a subprocess via ProcessPoolExecutor — signal.alarm() works in each subprocess's main thread
2. Enforce outer timeout with future.result(timeout=30) as fallback
3. Lazy-initialized process pool (4 workers) with thread-safe singleton pattern
4. Import math_verify inside subprocess function to avoid pickling issues

Checklist Before Submitting

• Read the Contribute Guide.
• Apply pre-commit checks
• Add / Update the documentation — no doc changes needed.
• Add unit or end-to-end test(s) — validated via training experiment.

[gemini-code-assist]

Code Review

This pull request refactors the math_verify utility to execute scoring within a subprocess using ProcessPoolExecutor, which prevents issues with signal.alarm() in multi-threaded environments like Ray. The review feedback highlights several critical improvements: defining a placeholder for TimeoutException to avoid NameError when the library is missing, using the spawn multiprocessing context to prevent deadlocks, and replacing a silent exception handler with basic logging to aid debugging.

[gemini-code-assist]

If math_verify is not installed, TimeoutException will not be defined in the global scope. This will lead to a NameError when compute_score attempts to catch it in the except block at line 58. Since this NameError is then caught by the broad except Exception at line 60, the function will silently return 0.0 without any indication of the missing dependency or the underlying error. Defining a placeholder exception ensures the code remains robust even when the package is missing.

Suggested change

	from math_verify.errors import TimeoutException
	from math_verify.grader import verify
	from math_verify.parser import ExprExtractionConfig, LatexExtractionConfig, parse
	except ImportError:
	print("To use Math-Verify, please install it first by running `pip install math-verify`.")
	from math_verify.errors import TimeoutException
	except ImportError:
	class TimeoutException(Exception):
	pass
	print("To use Math-Verify, please install it first by running pip install math-verify.")

[gemini-code-assist]

Using ProcessPoolExecutor with the default start method (which is fork on Linux) can be dangerous in multi-threaded environments like Ray workers, as it may lead to deadlocks or inconsistent state in the child processes if the parent process has active threads during the fork. It is safer to use the spawn start method by providing an explicit multiprocessing context.

Suggested change

	_pool = ProcessPoolExecutor(max_workers=4)
	import multiprocessing
	_pool = ProcessPoolExecutor(max_workers=4, mp_context=multiprocessing.get_context('spawn'))

[gemini-code-assist]

The broad except Exception: pass block swallows all potential errors, including critical ones like PicklingError (if arguments cannot be sent to the subprocess) or the NameError mentioned previously. This makes debugging extremely difficult in a distributed training environment. It is recommended to at least log the exception or catch more specific error types.

Suggested change

	except Exception:
	pass
	except Exception as e:
	print(f"Error in math_verify compute_score: {e}")