Neat! Is this how "threads" are spawned? or are forked processes different
from threads?
If this is how threads are spawned, how do big commercial apps manage to do
multiple things at once without completely duplicating the entire executable
in RAM? or is Perl's implementation less robust than the one used for
C++-type apps?
Forking a process and threads are two different things actually. Forking makes a copy of the running process. From there, the parent and child processes can do separate things. Threading is using different streams of execution. There's only one process there, but it's doing multiple things internally. Really, they're two different ways to solve the same problem.
Traditionally, forking was the UNIX way to handle this, while a lot of other platforms preferred threading. Today, you usually have both options available to you in most cases. (Windows doesn't generally support forking, but Perl on Windows does with heavy magic.)
Personally, I find forking a little easier to setup and follow. As you noted though, copying the entire process is a less than ideal use of resources, so threading is generally a little more robust, for most things.
Going back to servers as an example, forking works out pretty well for a web server that just needs to hand incoming requests the page they asked for (oversimplified a little). However, forking a chat server would generally be a bad idea, in my opinion. Once you had 50 users talking to each other, you would have 50 copies of all the state information the server tracks. Threading would server better here. (Technically, you can do both of the above with Non-Blocking I/O as well, eliminating the need to fork or thread. That's significantly harder though and off topic for this discussion.)
As a final detail, you will probably need to compile your own version of Perl if you want to use its threading options.
Hope that clears some things up.
James
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
