![]() |
| | #1 |
| Registered User Join Date: Oct 2002
Posts: 72
| How to make a thread sleep or std::recv timeout? This works fine and dandy (albeit ineloquent), but it forces a 1 second sleep every time the function gets called. What I'd prefer to have happen is to spawn both threads, make the "kill" thread sleep for a second, and have the program wait for the send/recv thread to finish with a pthread_join function. This way, if the send/recv thread finishes, the "kill" thread tries to kill something that doesn't exist, and everyone is happy, furthermore (if my thinking is correct), the program execution time won't be effected because even though the kill thread is sleeping, or pausing, or pthread_delay_np'ing, no one is waiting on it to finish - so everyone continues on their merry way. Is this a good way to go about it? If so, how can I make the thread sleep (sleep(1) doesn't seem to work correctly in a thread - it makes all threads sleep(1), and if I try it without a sleep, the kill thread kills the send/recv thread before it's had a good chance to finish)? As an alternative, is there a way to make the recv function time out? edit: I've tried nanosleep, but that seem to have problems & doesn't always work as advertised. This could possiby be due to the fact that I'm writing plugins for another application that may set some compiler flags that disables this ability? I'm not sure. |
| BrianK is offline | |
| | #2 |
| I lurk Join Date: Aug 2002
Posts: 1,361
| Asynchronous sockets may be another option. Here's a great article which I followed: http://www.gamedev.net/reference/art...rticle1297.asp (windows specific) |
| Eibro is offline | |
| | #3 |
| Registered User Join Date: Oct 2002
Posts: 72
| Sorry for the delayed reply - I'll take a look at fragmented send/recv. setsockopt( ) looks like it might be what I need. I agree that there's likely a design problem somewhere else in the code - glancing over it doesn't bring up anything obvious, so it will take some time to find. However, people are already using it, so I'm looking for a temp fix until the root of the problem is found. Thanks again for the suggestions, if anything else comes to mind, feel free to post. Any good book suggestions for TCP or UDP programming, especially in Linux/Irix? |
| BrianK is offline | |
| | #4 |
| Registered User Join Date: Oct 2002
Posts: 72
| >>if anything else comes to mind, feel free to post. > Running a Pthread each time to kill it after a while is pretty kludgy. I agree - the setsockopt( ) removes the need for the thread work-around. I didn't like it to begin with - wish I had known about the socket option thing a couple weeks ago. Thanks for the tip. It works much better this way (with socket options) and removes the horrid behavior of waiting one second between each request. >>However, people are already using it, so I'm looking for a temp >>fix until the root of the problem is found. > How much code? "wc -l" on the server files says about 4000 lines FYI: I based the server on Jeff Donahoo's Practical Sockets library (used with permission) - though I've had to modify it a bit to suite my needs. The clients use simple ::send ::recv commands. I could certainly post the relevant bits up here, but it seems a bit much. Getting some good instruction on network programming is going to help loads - I'll take a look at that book before I start asking a bunch of questions. Thanks again! |
| BrianK is offline | |
![]() |
| Thread Tools | |
| Display Modes | |
|
Similar Threads | ||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Calling a Thread with a Function Pointer. | ScrollMaster | Windows Programming | 6 | 06-10-2006 08:56 AM |
| Sleep is overrated... | Polymorphic OOP | A Brief History of Cprogramming.com | 24 | 01-24-2003 12:40 PM |
| Thread sleep | quagsire | Linux Programming | 2 | 12-09-2002 02:42 PM |
| MFC Controls and Thread Safety :: MFC | kuphryn | Windows Programming | 0 | 12-06-2002 11:36 AM |
| Sign up -- Contest Thread | ygfperson | A Brief History of Cprogramming.com | 70 | 05-27-2002 06:46 PM |