take a good class on operating systems if you really want to understand all the details.
in the meantime, here's my best shot at an explanation:
threading allows for concurrency. concurrency means doing more than one thing at a time. the benefits of doing more than one thing at a time should be fairly obvious.
of course, perl already has a form of concurrency with fork(), which spawns a new child process, so why would we care about threading? spawning processes is inefficient and cumbersome in many situations. spawning a process on most operating systems requires copying large chunks of memory and modifying process tables; this is slow. then, once the new processes are spawned, they're totally seperate; they can't share data very easily without the use of inter-process communications (IPC) which are tricky things to handle. making seperate processes work together on a single task gets mind-bogglingly difficult very quickly. (don't think i'm bashing fork() here; spawning new processes is a perfectly good way of accomplishing many tasks. i use fork() all the time.)
so threading comes in for situations where you want to have lots of things going on at the same time, probably with a good deal of communication and cooperation between all of the seperate tasks (threads). it's probably simplest to think of threads as lightweight processes; the process of spawning a new thread is very similar to spawning a new process but involves far less copying and fewer calls to the operating system itself (which tend to have expensive context-switches). threads are also generally allowed to all access the same data (with some provisions for synchronization) which makes communication and cooperation significantly easier.
if that's not terribly clean, let me know and i'll elaborate.
anders pearson // digital samurai
personal // http://www.columbia.edu/~anders/
weblog // http://thraxil.dhs.org/
| 