C++ sockets dilemma

[RHLinuxNewbie]

I'm writing an IRC bot in C++, and I've come to the point where I want to implement a queue. I've already written a good portion of the program, it connects, responds to commands, etc. I've added the queue code, to where any information going out is added to an array, and later will be pulled out and sent to the socket with a timing of one second between commands.

The problem arises when the recv() function is called, being the socket is blocking, the queue cannot be called because the program is waiting for incoming data. Is there a way around this? I've read about the select() command ( http://www.ecst.csuchico.edu/~beej/guide/net/html/advanced.html#select ), but to be honest, it's a bit confusing and may yield the program to use excessive amounts of CPU by constantly checking the socket then the queue. Any thoughts, ideas, or suggestions? Thanks.

[Energon]

As long as in your select() loop you sleep(), you won't bring the system to its knees. I'd say learn select() because it's the best method. You could also use threads, but select() will provide better results and you'll learn more.

[Spawn913]

Personally, I think using threads would be the best solution you could do here. One thread would wait for data on the socket, while the other would process the queue. Thru a semaphore, you could pause the operation of the second thread whenever there's new data on the socket.

select() is good, but for your application, I think it won't be too useful since you *have* to check the queue everytime -- meaning that you'll always have to poll on both the socket and the queue.

[Energon]

Why make life difficult with thread safety when select() works fine? The razor wins every time, no doubt.

Or he could combine both and have a dedicated network thread and a dedicated processing thread.

[Spawn913]

well, in my opinion, having to use select() is sort of an overkill for an application that will poll anyway. select() is great if you want to pause execution until some data arrived on one or more ports, but in this case, a simple non-blocking read(), and then a sleep(), would do the same job.

The added functionality in select() would only slow down execution as compared to just using nonblocking I/O.

In my opinion, the threads solution is more elegant (and more conservative on resource usage).

Anyway, the thread synchronization for his code doesn't seem that complicated; one semaphore can do the job. (i think :rolleyes: )

just my opinion....

:cool:

[majidpics]

Try with recvmsg with MSG_DONTWAIT option

[Energon]

Probably the best thing to do is just try them all and see which one ends up working the best for the job.