Re^3: Module for transparently forking a sub?

If I wind up writing one, maybe I could steal the interface from threads for it.

That already exists, but it just as vulnerable to thread-safety problems as ithreads--eg. you probably won't be able to run concurrent DB queries safely; and if you're lucky enough to find thread-safe drivers, concurrent queries will likely not run any quicker than they do serially. And it is not a cross-platform solution; threads is!

And for passing back complex data structures, serialising them through a pipe is far slower that using shared memory.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Comment on Re^3: Module for transparently forking a sub?

Replies are listed 'Best First'.
Re^4: Module for transparently forking a sub? by kyle (Abbot) on Feb 13, 2009 at 22:12 UTC
I don't think I understand your reply, so I'm wondering if I wasn't clear. What I meant was that if I write a module like the one I was looking for (which does with fork what you demonstrate with threads), I could use methods with the same names and calling conventions as threads (e.g., `Foo->create( { context => 'list' }, \&foo )`, `$child->is_running()`, etc.). The interface already defined for it looks nicer than what I had in mind before I read about it. Using it would also mean that someone who becomes familiar with one will have an easier time switching over to using the other one if circumstances warrant it.	[reply] [d/l] [select]
Re^5: Module for transparently forking a sub? by Corion (Patriarch) on Feb 13, 2009 at 22:18 UTC
Like forks?	[reply]
Re^6: Module for transparently forking a sub? by kyle (Abbot) on Feb 13, 2009 at 22:24 UTC
Yes! That's what I was looking for all along! Thank you!	[reply]