Home » U++ Library support » U++ MT-multithreading and servers » how to stop a thread that is waiting, e.g., listen()
|
|
| Re: how to stop a thread that is waiting, e.g., listen() [message #11803 is a reply to message #11802] |
Wed, 26 September 2007 13:05   |
 |
tvanriper
Messages: 85
Registered: September 2007
Location: Germantown, MD, USA
|
Member |
|
|
You could probably do this with a signal. Normally, threads allow you to have multiple signals at one time. You are using one of those signals right now to wait on your networking socket (or whatever you're doing)... so you could create another signal to indicate that you have some kind of message for the thread.
The message could be stored in a variable that's protected by a mutex.
When the thread gets the signal, it looks in the variable, sees that you want it to close, and then stops itself (cleaning up any variables it needs to clean up).
It's not recommended to try and forcibly close a thread, as you seem to suggest wanting to do, because this will not deallocate variables you have (implicitly or explicitly) allocated for that thread.
|
|
|
|
|
|
| Re: how to stop a thread that is waiting, e.g., listen() [message #11835 is a reply to message #11802] |
Thu, 27 September 2007 13:20 |
|
tvanriper
Messages: 85
Registered: September 2007
Location: Germantown, MD, USA
|
Member |
|
|
Sorry... I have mostly worked with Windows programming, where the term 'signal' takes on a slightly different meaning, I think. At the very least, I meant the word in a far more generic way than I think you took it.
I can't really speak too clearly on POSIX-oriented programming, and I still need to peek a little more closely at how Ultimate++ handles threading in general, but while there might be commands to kill a thread, that normally means you're ending the thread before it has had a chance to clean up. Especially for long-running applications, this is not a good idea.
In general, regardless of platform, you want to somehow tell the thread, while it's running, that it should stop running, so it can clean itself up. That's all I'm trying to say.
In the Windows world, you do that through an event/signal.
I get the impression that, in the POSIX world, a signal interrupts the flow of the thread... that isn't what I'm aiming for. At least, I don't think it's what I'm aiming for... but again, I am not very experienced in POSIX. I could be completely wrong.
Somehow, while your thread waits for information to arrive on the socket, something tells the thread that it can stop waiting, and handle the network information. That same mechanism should also be able to provide a way of telling your thread that it can stop waiting, and start handling some other kind of information (in this case, checking a variable to see if the thread should quit). While I know how to do such a thing in Windows, I do not know how to do such a thing with POSIX, and I'm not entirely sure (yet) how Ultimate++ handles it... but I expect you could probably figure it out by examining the Ultimate++ code.
|
|
|
|
| Re: how to stop a thread that is waiting, e.g., listen() [message #11837 is a reply to message #11802] |
Thu, 27 September 2007 13:43 |
|
tvanriper
Messages: 85
Registered: September 2007
Location: Germantown, MD, USA
|
Member |
|
|
Out of my own curiosity, I took a peek at Thread.h/Thread.cpp in Core, and socket.h/socket.cpp in Web.
Thread.h/.cpp detail the Thread class, a class you can use for handling multi-threaded needs in an application. It exposes a Wait function, which returns an int. The integer it returns is either the exit code for the thread, or a numeric identifier for an event that was sent to the thread (well... in Windows... in POSIX, it seems to work differently, if I am reading this correctly... pthread_join [which will return 0] or the return value of the terminated thread).
For Windows, the Socket class seems to support the use of the Event object, but that object is not exposed to POSIX, if I'm reading everything correctly.
At a guess, you could probably create a Socket, set it up for networking however you need to, and use the static 'Wait' command with a timeout to wait on network traffic. If there's traffic, do what you need to do with the traffic. Otherwise, check a variable shared between your threads to see if you need to shut down your thread.
Perhaps someone else might have a better way to do this, but this seems to be the safest way to handle Sockets, multi-threading, and keeping your application working in both Windows and POSIX environments.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: how to stop a thread that is waiting, e.g., listen() [message #12266 is a reply to message #11802] |
Mon, 22 October 2007 17:47 |
|
tvanriper
Messages: 85
Registered: September 2007
Location: Germantown, MD, USA
|
Member |
|
|
Well, it's maintained separately, by the boost folks, but since it's just C++, I'm sure you could use it in addition to the Ultimate stuff if accomplishes your needs.
Goodness knows, I mix Ultimate++ with the standard C++ library (io streams, maps, etc) whenever I feel the need, without any adverse side effects. I haven't tried mixing with boost yet, but I can't imagine there'd be any problems.
I would heed the advice boost gave regarding event driven multitasking. They suggest that it's fraught with peril. Er, that it has a tendency to lead to some multi-tasking problems of one form or another. Basically, it has a tendency to lead to unsafe code, while some of the other approaches they recommend lead to safer practices.
|
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Fri May 09 16:06:03 CEST 2025
Total time taken to generate the page: 0.03196 seconds
|
Members
Pages
Help
Register
Login
Home
