Forking and threading are two fairly different things. I can even see situations where you would want to do both at the same time. Overlooking the fact that threads don't seem to work as well cross-platform as forks do, and that I haven't done any real work with threading (not in perl), I'll give my opinion anyway:

When you fork, the child program and parent program really do go their separate ways. Ignoring the few signals and what not that tie them together, they are now separate programs. They shouldn't be talking to each other, except possibly by signals and in desparation, shared memory. They can do some very nifty things, like the Apache server which runs as root, but forks off children that run as nobody - which is part of the reason it has the best reputation for security. Even a hacked Apache server is mostly useless - the best you can do is vandalise the website. Note here that Apache's children do not communicate (much if anything) back to the parent. If you wanted to have the children change variables in the parent, you really want threading.

Threading is extremely nifty when you want the program to momentarily 'split' and then 'recombine'. Nothing is better for updating a user interface while waiting on a port than threads.

Of course you could do both at the same time - listen on multiple ports and then fork children. It's no accident that Perl is better at forks - Unix in general is better at forks. But it is a hammer that gets used on a few too many problems.

____________________
Jeremy
I didn't believe in evil until I dated it.