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.

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.

Like forks?