By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,963 Members | 1,259 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,963 IT Pros & Developers. It's quick & easy.

pth_select not blocking

P: 12
I'm using C++ in Linux to read UDP and TCP sockets. I am now trying to impliment multithreading using pthreads.

pthreads has forced me to replace many of the standard socket functions (select, sleep, send, etc) with "pth_" replacements (i.e. pth_select, etc).

Problem is that pth_select isn't blocking. I.e. it isn't waiting for something to come over the sockets, it's simply checking the sockets then continuing. Sort of like what would happen if the time-to-wait before timing out was set to zero.

Thus I'm using all my CPUs to simply run around a while loop constantly checking the sockets.

This code worked fine before pthreads and pth.h was introduced, i.e. I'm confident that I actually have a wait time defined because it was waiting before.

Any help or directions to help would be very welcome. Thank you in advance.
Jun 13 '07 #1
Share this Question
Share on Google+
2 Replies


weaknessforcats
Expert Mod 5K+
P: 9,197
Usually for a thread to wait on another thread it has to check an event. The second thread can signal the event (raise the semaphore) and this can be picked up by the first thread as the OK to continue. Think traffic lights.

Have you set up semaphores?

Check your docset for thread handling.
Jun 14 '07 #2

P: 12
The problem isn't with the threads directly, I can comment out all thread issues so that I only have the main.

Select (and thus pth_select) are supposed to wait for the socket to hand me information (which I then intend to hand to a sub-thread but that's a moot point with it commented out).

I found a report claiming Select had problems in combo with threads (which I can confirm) and I was supposed to use the replacement pth_select.

Pth_select isn't blocking, i.e. it's not waiting for information to come over the socket. Thus I'm using 100% of my CPUs to check and re-check the select for information when it's actually supposed to continue only if it actually finds something (or times out).
Jun 14 '07 #3

Post your reply

Sign in to post your reply or Sign up for a free account.