Question

I have an application that I'm working on that requires a couple of secondary threads, and each will be responsible for a number of file handles (at least 1, upwards of 10). The file handles are not shared amongst the threads, so I don't have to worry about one secondary thread blocking the other when selecting to see what is ready to read/write. What I want to be sure of is that neither of the secondary threads will cause the main thread to stop executing while the select/pselect call is executing.

I would imagine that this is not a problem - one would imagine that such things would be done in, say, a web server - but I couldn't find anything that specifically said "yes, you can do this" when I Googled. Am I correct in my assumption that this will not cause any problems?

For clarification, what I have looks something like:

  • Main thread of execution ( select() loop handling incoming command messages and outgoing responses )

  • Secondary thread #1 ( select() loop providing a service )

  • Secondary thread #2 ( select() loop providing another service )

As I previously mentioned, none of the file handles are shared amongst the threads - they are created, used, and destroyed within an individual thread, with the other threads ignorant of their existence.

Was it helpful?

Solution

No you don't have to worry about them blocking the main thread. I have used select in multiple threads in various projects. As long as they have distinct FDSETS then you're fine and each one can be used like an independent event loop.

OTHER TIPS

Isn't select supposed to block the whole process? Have you tried to set the nonblocking mode on the socket?

Also, see select_tut manpage for some help.

Here's a relevant section from the select_tut manpage:

So what is the point of select()? Can't I just read and write to my descriptors whenever I want? The point of select() is that it watches multiple descriptors at the same time and properly puts the process to sleep if there is no activity.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top