Sorry to post a non-responsive reply, but I feel I have to comment on the following:

After few hours of scanning through POE docs I'm begginng to think that it's more of cool-idea then working system.

Perhaps you meant it's not workable in your case, and you may well be right about that. There are many times when POE is not the right choice, and many times when it would have been the right choice, but rewriting lots of code is not worth it. No reasonable person would disagree with that, and if that's what you meant, then please ignore the next paragraph.

If, however, you meant what you literally wrote -- that POE is not a "working system" -- then you are dead wrong. I've used POE for numerous projects in the short time since I first learned it. I have quite enjoyed those projects. It is definitely a working system, by any definition of the term. Furthermore, to make such a statement after simply scanning the docs is foolhardy and silly. I know (from experience) that POE seems rather strange at first, and it takes some actual use before it clicks. Once it does, things start to make a whole lot of sense, and it becomes a very nice system. Perhaps you will give it a shot with another project sometime.

PS: I hope this reply isn't taken the wrong way; I really am attempting to clear up what seems like a possible case of misunderstanding. I write with the best intentions.

I looked at POE, but it makes you re-design your whole app around it, and for my needs I'd have to recreate some of basic POE components to suit my app. After few hours of scanning through POE docs I'm begginng to think that it's more of cool-idea then working system.

Rocco would probably disagree, but in my experience POE does try to change your app. It is, however, a very cool infrastructure -- though if you want to design your lightweight message-broker/event-handler, that's not such a bad thing to do -- it keeps you from having to POE-ify your app, and you learn something from reinventing the wheel.

If you were starting something ground up though (and you know the interdependencies will be complex), POE is a good choice. It sort of feels like programming an embedded system or a microcontroller sometime, the programming style is very very different -- your just can't attack the same problems in the same ways.

Also depending upon what each does, and it sounds like it may be a 3-tier system where some parts are just processing data, these could probably be run as a system service/daemon, and left running, just restarting when you actually change the code. (ie, run and forget, and just start the client/interactive bits, when you need them.)

It's difficult to suggest specific solutions, without knowing more about the nature of the program.

(A third idea, have one part start the other parts, configurably?)

C.

That's how I'm doing it right now.

But this way the system behaves like three different, independant apps, this is good - I can stop, start, restart any part of it, and bad - it's three different daemons, and when I hand out maintainance to someone else I need to explain the inner workings of the system - it doesen't behave like a single system to them.

It's a bit like hmm, say, Oracle database, it consist of various important parts, and I would prefer it to behave more like single daemon, like apache webserver.

If I would merge this into single binary, that forks itself to handle various tasks, I would loose ability to easily manage those parts. So this is how it would look like with apps split into two parts:

my $child=fork();
die "Can't fork: $!" unless defined $child;
    if ($child) {
      handle_task_one();
    } else {
      handle_task_two();
    }
[download]

Looks almost ok... but now with three parts:

my $child=fork();
die "Can't fork: $!" unless defined $child;
    if ($child) {
      handle_task_one();
    } else {
      my $childschild=fork();
      die "Can't fork: $!" unless defined $childschild;
      if ($childschild) {
      handle_task_two();
      } else {
        handle_task_two();
      }
    }
[download]

Now it becomes unreadable. I got away with it when I created pool of worker 'threads', but with different functions I would prefer my code to look a little better.

So don't merge it. If you look at an Oracle install, or any other sufficiently large software, you'll see it consists of a whole bunch of executables, DLLs and so on. It just has a single Interface, which starts and stops bits as needed. The argument of needing to explain how it runs to someone else isn't really one, if that's how you've designed it, then thats how it is, describe how it works to them.

It really does sound as if you need one overall script, which runs the others.. Why fork? Why not just run them using system() or similar? (I assume your three parts already have some external method of communicating). That way you get to keep the code in separate, easily managable scripts.

Alternatively, you don't need to copy all the code into one script to have it run together, using modules and such will keep the actual code separate, but allow it to act as one. Eg. make a module for one part, do 'use Module;' and 'Module::Run();' to get it started ?

(Forks are yucky, if you ask me ,)

C.