Is that call to fork, the only call to fork in your program?
Does this happen the first time you execute that line of code? If not, how many times have you successfully executed that line before it fails?
Tip: If you have not already done so, start the task manager, select the "Processes" tab; click View->Select columns... and ensure that "thread count" is checked, click OK. If the "threads" column is off the right hand side of the page, you can drag the column left into a convenient place.
Add print "Check?"; <STDIN>; before the fork. That will allow you to check the task manager before/after each fork.
Beyond that, the most likely scenario is that one or more of the modules you have loaded is not thread-safe.(You do realise that under win32 fork is threads->create in disguise?).
Each time you call fork, Perl will CLONE everything you currently have running into a new interpreter. Many modules, and especially many XS and C components of modules are simply not set up for this and get very confused when their resources are CLONED.
Also, if you are using objects (for example $this in your sample code), then each of your "forks" will get its own copy of each existing object. However, if one or more of those objects contain, or make use of a process global resource--filehandles, sockets, non=thread-safe C libraries etc.--then you are likely to have invisible and unarchitected interactions between the CLONED object instances that think that they are running standalone in separate processes by are not.
I wish I could say that life were simpler or better if you switch your program to using threads--but it isn't. There is still no way to create a virgin thread, or defeat the CLONING mechanism. You do however exercise at least some control over when threads are created, and therefore what gets loaded into them. With care, it is possible to resolve most problems onec you understand that you are not operating in a normal forking environment.
Not much help I know, but no one is listening. Rather than giving the programmer the ability to control what gets loading when, 'they' appear to insist on trying to pursue the threads are forks mechanism and are adding more CLONING rather than less. Stupid, but true.
In reply to Re: multithreaded debugging
by BrowserUk
in thread multithreaded debugging
by Razvanica
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |