I am not aware of any problems that that a threaded build of perl causes for non-threaded applications, apart from a minor drop in performance.

As for writing threaded apps, bear in mind the following:

• use the latest possible perl, ie 5.8.7; user-level threads only appeared in 5.8.0, and there have been many fixes in the minor releases that followed.
• Perl ithreads are generally less efficient than forking; fork() uses the OS's memory-management facilities to do copy-on-write of the process's pages in hardware, while perl's threads->new() goes through the entire interpreter's data structures and copies each individual variable etc (only code is shared, not data).
• Shared data in perl's ithreads is very expensive, both in terms of speed and memory usage. A shared scalar variable usually has a copy in every thread that uses it, plus a separate shared copy. When you assign to a scalar, the thread's copy is updated, then that data is also copied to the hidden shared copy. When you read from a shared scalar, the data from the hidden shared copy is copied to the thread's one. Thus if you have N threads all accessing a long string variable, your memory usage will tend towards (N+1) times the length of the string.
• Shared arrays and hashes use a mechanism similar to tieing, which means that they are slow, but not too memory-inefficient.
• Try to avoid having complex, deeply-nested shared data structures

Dave.