I think most system perls are nowadays compiled with ithreads enabled. There is the forks module that emulates threads with fork() and Storable I believe. I'm not sure what you want to use threads for, so I cannot comment on the feasibility of using fork() instead.

This is as part of the client for a file-syncing application, somewhat like Dropbox. (It's a university project.) It basically has three broad responsibilities—monitoring the filesystem, watching the server for remote changes, and uploading and downloading files. I'd like to split these into three communicating threads or processes.

Using threads would allow me to pass full objects around through something like Thread::Queue, instead of having to serialize the data somehow onto a socket or pipe, so if that's a viable solution it strikes me as likely being better.

=cut
--Brent Royal-Gordon

My reading of the tea leaves says you're planning on rolling this app out onto a bunch of oddball departmental servers which are probably not under your direct control. If your school is anything like the university I worked at, that means some of those machines are crust old boxen that should just be shot and put out of their misery, but geology has to have that exact version of perl 4 to support their favorite app. Sigh.

So, what happens if the threaded code doesn't work on every single machine? Is the project a failure or will your PHBs be happy with 95% coverage? Can you go install a private version of perl on the machine in question? Is that ancient server lurking in some obscure corner of the campus going to come back to haunt you?

That said, sure, reasonably up to date versions of perl will typically be compiled with ithreads on the major platforms. Really, it's up to you to make the call, but those are the points I would consider.

But it always pays to test, test, test. Some of us here have the scars to prove it.

The ports for perl (5.8 and 5.10) on FreeBSD build with threading disabled by default.