Genius
Genius

Reputation: 589

Alternatives to select() on client side

Is there an alternative to select() for the client side of a TCP non-blocking socket connection?

select() is mainly for multiple connections, but my client only has a single connection. As a result, I asked myself if there is an alternative function to recognise I/O on a single socket. That would probably be faster and I wouldn't need all the fd_set handling.

Upvotes: 0

Views: 2008

Answers (2)

Manoj Pandey
Manoj Pandey

Reputation: 4666

Select() helps you monitor both read and write events (and exception events) in one shot, so it does make things scalable rather than the application having to check (since it is non-blocking). You probably should clarify what is your end design objective. Of course, as someone mentioned, having two threads, one for read and write might do the same thing. In fact, if you have a higher workload, you can go beyond two and actually keep a pool of threads.

Upvotes: 2

nouney
nouney

Reputation: 4411

You should use select() in the client, and it will not be faster if you're using select for just one socket.

By the way select() isn't for multiple connections ... in real-world, due to its performance issues. Just for your information, take a look at /dev/poll/epoll()/kqueue() and io completion port for Windows.

Upvotes: 0

Related Questions