Thread support in Java is pretty robust, and I think that's the way you'd handle this type of problem. Rather than forking children and communicating with them, in Java you'd use threads to do the work.
| [reply] |
If you really need processes, this could be a big selling point in favour of Perl.
Java fork emulation is a real pain in the ass: you basically have no easy way to fork the current process, so you have to call Runtime.exec() and pass it the Java class to execute. This fires up a new JVM, which takes a lot of CPU and memory. Then, you'll also have major problems in communicating between the various JVMs, since Java does not (natively) offer anything like pipe or the inter-process communication tools offered by the various IPC::* modules, so you basically have to resort to JNI, or you have to use sockets, RMI, or even CORBA (one can also resort to EJB, that's true, but this could be an overkill and an unmistakable source of major headaches).
As for threads, though it's true that Java prefers threads over real processes (and their implementation in Java is robust), it is important to stress that threads are not real processes.
For instance, real processes will seamlessly migrate over an SSI cluster of machines (as long as they don't use shared memory), while threads will not.
Also, an application based on real processes rather than on threads is much more robust, since each process runs in a separate address space while threads all live in the same address space, so that a single thread crash can bring down the whole application.
And forking a new process is only marginally slower than creating a new thread, on systems that use Copy-On-Write (basically any modern *nix).
Ciao,
Emanuele.
| [reply] |
