Persistent Perl interpreter accumulates mixed old and new code after repeated do FILE

Recommendation

Prefer a socket-owning supervisor that starts fresh Perl processes and retires old workers over repeated do FILE in one interpreter. Use in-process reload only when the application is pure Perl, has a single reload coordinator, and you can prove the symbol table is clean; otherwise stale XS state and duplicate subroutines make mixed code likely.

Why do FILE accumulates mixed code

require records the path in %INC and skips later loads, so it cannot hot-swap definitions. do FILE re-executes the file, but it does not clear the package stash or update %INC consistently. Repeated execution can redefine subroutines while older symbol-table entries remain, especially when package declarations or lexical scopes change between versions. XS modules add C-level state that do cannot reset.

Perl build characteristics that affect socket handoff

• useithreads: threaded builds share file-descriptor tables and complicate passing sockets between threads.
• Fork semantics: Unix-like fork() lets descriptors survive; Windows uses pseudo-fork via threads, making true socket handoff harder.
• XS modules: global C state may break across fork()/exec() or survive in-process reload unsafely.
• useshrplib and signal handling: shared libraries and installed signal handlers can persist after reload.

Check the build with perl -V and look for useithreads, d_fork, and useshrplib. These steps assume Perl 5 on a Unix-like operating system unless otherwise noted.

Steps for this case

1. Run perl -V to confirm whether the build is threaded and whether fork() is available.
2. If the build is non-threaded Unix-like and the code is pure Perl, deploy with a supervisor that holds the listening socket. On code change, spawn new workers with the updated files, stop accepting on old workers, drain in-flight requests, then terminate the old workers.
3. If the application loads XS modules, runs threaded Perl, or targets Windows, avoid in-process reload. Use process replacement or a separate supervisor process that creates the socket and spawns workers.
4. If in-process reload is mandatory, enforce one reload coordinator. Before re-executing, run delete $INC{'Module.pm'}; undef %Module::;, reset %SIG, and drain requests.

Checks for mixed old and new symbol-table state

• Compare subroutine references: capture &Package::sub before and after reload. A changed reference means the subroutine was replaced; an unchanged reference may indicate stale code.
• Use Devel::Symdump->new('Package')->functions to enumerate subroutines and look for duplicates or orphaned entries.
• Run a targeted health-check endpoint that exercises critical code paths after reload.
• Inspect memory with Devel::MAT after several reload cycles to detect accumulated stashes.

Missing diagnostic detail

Does the application load any XS modules? If yes, rule out in-process reload regardless of Perl build.