I dunno if it will suit your needs (it's not really like fork) but I have had some decent success with Win32::ProcFarm for various projects requiring "doing stuff in parallel".
If this isn't quite what you need, you may at least be able to look at the guts to see how the author is handling the various "procs" in the "pool" and see if you can modify it to suit your needs. | [reply] |
What crashes? I thought fork emulation works pretty well for Perl stuff.
As for alternatives: a few years ago, I wrote a protocol monitor by implementing the multithreaded queued read/write part in C++, but embedded a Perl interpreter for processing the data being "tapped". You can embed perl.dll and run interpreters on several threads. | [reply] |
The most prevalent is "The instruction at 0xblah reference memory at 0xbleech. The memory could not be "read"
Strange thing is that it is not a consistant crash. I can run a program that does this 2-3 times without a crash, and then 2-3 times with the crash.
UPDATE: The other thing I should mention is that all proggies that do this to me execute flawlessly under FreeBSD.
Rex(Wrecks) wishes he could be in league with the little red devil always
| [reply] |
So a program that uses ActiveState's fork() is giving stray pointer crashes when run, sometimes?
Any machine-level stray pointer in a pure Perl (no XS, no API calls) program is by definition a Perl bug.
In a compiled language, a debugger easily spots the instruction doing that and lets you view the stack to see what it was up to. I don't know how you'd do it in Perl. A general-purpose mechanism would be to "confess" the stack trace any time a machine-level exception or signal is encountered. I have no idea how to set things up to do that, but I think it ought to be built-in.
—John
| [reply] |