Anonymonk pointed out that:

you're conflating unrelated things, fork is not implemented using threads module

In reply to a post where you used a bug in Perl's Windows fork emulation as a justifiction for not using threads, nor even building your *nix perl with threading enabled.

Your misunderstanding is to equate all bugs with the former, as bugs with the latter also. They most frequently are not. Here is a simplified explanation of that.

Anyone that does not use the fork emulation, either because--like me--they do not see any advantage to it; or because--like you--they use an OS that doesn't need fork to be emulated, will not be affected by bugs in that emulation, even though they might use threads regularly.

Although both are based around the concept of running a separate interpreter in a new thread--ithreads. They are implemented in quite different ways (with some common code), to achieve quite different things.

When the code reference passed to thread->create() starts running, it is at the very root of the call-stack in its interpreter. That is, it inherits access to pre-existing code and data, but its call-stack, and all its other stacks, are empty. There are no pending returns to be returned from. No complex of unclosed scopes to be unwound. No half executed if statement that must be conditionally branched.

Just a coderef that must be executed in the context of some preloaded code and data. Pretty much exactly the same as when main::main is called in a new, single threaded program. That is, all the use statements have been processed, all the BEGIN/CHECK/INIT blocks have been run; some namespaces, coderefs and data have been preloaded, and it is time to run the program.

The only real differences between the 'new thread' case and the 'new process' case are: a) the entrypoint isn't called main:main; b) the namespaces, coderefs and data didn't need to be loaded from disk, source code parsed and tokenised, opcode trees built etc. A quick block copy and it is ready to go.

Contrast that with the fork emulation case where the program is already in mid-flow. The program is usually in the middle of a if statement; often embedded within a half executed loop; usually several layers, and potentially dozens of layers of scope down. Potentially in a recursive call chain. Perhaps within a BEGIN or END block. Maybe embedded within several layers of to-be-unwound exception handling. Perhaps with unhandled pending signals, timers or whatever.

In order for the fork to work, all of this state--half executed opcode stack, code stack, save stack, temp stack, curstack and mark stack--have to be captured and faithfully reproduced, in addition to the preloaded state that a new thread needs. And the scope [sic] for getting that lot wrong is far greater than simply copying the preloaded state required by a new thread.