The concept of threads is to control concurrent use of the same code. If the two processes are intended to execute different code concurrently, you probably want to use fork instead

No, the difference between threads and forking is that threads share the same memory while forked processes do not. Forked processes often run the same code and threads often run different code (though they can't run different programs, of course).

The practical differences between sharing memory and not is that threads will usually have to use locks to prevent conflicting accesses to the same bits of memory but can also just store data in memory to later be used directly by another thread. While processes need to use IPC to send data back and forth and very often don't need to use locks. Note also that getting locking right can actually be a significant technical challenge when using threads, especially as the software gets older and more complex (so using separate processes is often considered "safer").

The original poster noted "I create a reader thread". Using fork to create "a reader" doesn't actually help because the new "reader process" would have to send the read data back to the parent via IPC which means the parent would have to read data from the reader process, which likely poses the same problem that prompted creating a new thread in the first place.

Though, you could use non-blocking read or, to be even more efficient, 4-argument select to avoid creating a reader thread. Though that certainly adds some complexity as well, especially in Perl. And with a thread you can let Perl mostly deal with the locks for you so that is likely the simplest approach to code, anyway.