surely there are forking frameworks that are much smaller and easier to use than their big brothers. the reason why the bigger and more complex frameworks exist is because they do a whole lot more than a simple fork, typically allowing all sorts of scheduling and queueing. forking is their primary mechanism, but not their central goal.

That fine if you want everything they do; and if they do everything you want.

But if the former is not true, you have to carry its costs. And if the latter is not true, you are into the game of either waiting for them to provide it, or trying to understand enough of their internals to allow you to wrap over the modules--CPAN or your own--in such a way to make them compatible with the framework.

It all comes down to: Do I call them if and when I need them?

Or: Do I have to try and arrange for them to call me sufficiently frequent that if there is a possibility of there being something to do, I can poll around and see what, if anything, that might be?

(Oh. And then remember to store enough information about what I was currently doing before they interrupted me that I can pick it up when I get back to doing it.)

(Oh. And oh. And not forgetting that if I do find something to do, I'll need to retrieve whatever information I stored last time I was doing it. And then remember to store the modified state once I finished doing what ever it is that I found to do.)

(Always assuming that I succeed in finishing it and don't get interrupted again before then.)

(That's assuming that there was actually something else to do when I got interrupted.)

In a nutshell. Frameworks suck because they force me to work their way for everything. Even when most of the things I need to do aren't a natural fit to that way of working.

On the other hand, the nitty-gritty of forking and IPC can be encapsulated in a way that allows it to be used intuitively and without the need to invert the flow of control, or requiring bending the entire application to the will of the encapsulating module.