Contraversy has asked for the
wisdom of the Perl Monks concerning the following question:

Ok, I hope I am asking this in the correct place. I have a simple IRC Client that I want to make, there are a plethora of code snippets online for this. And I have 1/2 of a working client. It connects, responds to the PING requests and can even auto reply to any commands I want it to recognize and reply to.
But my problem is, I don't want a bot that idles or auto-replies. I want a basic, bare-bones client that can send messages as well as receive them.
If I try to add a loop/command to send a message it stops the entire loop and waits for me to input. I tried this in C++ using a non-blocking input command and still couldn't send any information.
My Main Question, do I have to open an extra socket? Simply for sending messages that I input?

There are a few approaches available here. The most obvious might be to use threads - one thread that would read from the socket (blocking), a second thread to write to the socket (blocks on the input queue used to feed it stuff to send), and a third to read from stdin (perhaps using Term::ReadLine). I'm not sure if that middle thread is quite needed, though it would handle race conditions between the first and last threads for sending stuff to the IRC server.

Personally, I do this basic type of thing with a single thread using event-based code, usually AnyEvent/Coro, though some will swear by POE. And, with a new enough Term::ReadLine, you can integrate it with Coro fairly well, or other event loops not quite so well, but still passably if done with Term::ReadLine being your main event loop (see Term::ReadLine::Event for example code), though there's always the issue of spitting stuff to the screen (input from IRC server) while waiting at a prompt.