I've been searching and reading about killing threads (C posix threads), and everybody says that is not a good idea because a thread should make its work and then return... but my problem is the next:
I'm reciving messages in my local network (using the recvfrom function), but this function "blocks" my program, I mean, if I don't revice any messege the function keeps locked (forever) until it recives something.
To avoid this, I thought to use threads, so, while my main thread is "counting", my second thread is try to recive messages. If in a determinated time (i.e. 1 second), my second thread is still waiting for a message (is locked in the recvfrom function) I need to "kill it" and then create another thread to start again (and try to recive messages from another IP). This means that not always my thread going to finish its work and I can't wait forever...
So far I can do that (create a lot of threads and recive the messages from the IP I'm interested in), but I don't know how to kill the threads that never recived anything...
Someone knows how to kill the threads? Or they are killed automatically when my main program returns?
Thank you and really sorry for my poor english...
Looks like its related to one of my questions How to avoid thread waiting in the following or similar scenarios (want to make a thread wait iff its really really necessary)?
But its .net, though (code sample is in C#)
Essentially i spawned new thread and performing some i/o oeprations and its a blocking call.
And for some reason it just waits foreve, i do have timeout so that i can abort the thread 'abort' method.
Rearchitect so the thread can receive messages from any IP. That way, you can try to receive messages from another IP without having to disturb the thread.
Related
I'm trying to debug a thread issue. In most cases, it's easy, but with this one something gets stuck and I'm having difficulties finding the threads that causes the issue. (It happens after several hours and writing logs breaks the timings so... it's difficult as I can't just change the code to help me find the culprit).
Today, I was thinking to:
Hit Ctrl-C
I tried to determine which thread it is:
thread 9
where
That looked like a good bet. A thread waiting for data on a FIFO...
I decided to verify my theory by entering:
finish
The program started again, but gdb never stopped...
Am I correct thinking that proves that this FIFO never receives any data and that's where my process is stuck? (i.e. when data is received that function returns)
Am I correct thinking that proves that this FIFO never receives any data
Yes: if your description is accurate, then it is likely that thread 9 is stuck waiting for data.
and that's where my process is stuck?
That we can't tell. A thread waiting on a FIFO could be expecting data from an external source (it is somewhat unusual and inefficient to have a FIFO that transfers data within a single processs), and if the other end of the FIFO is connected to some other process, then the fact that a thread was stuck there proves nothing.
P.S. One of the common ways that mixing FIFOs and threads causes hangs is also using fork or other functions which create subprocesses -- it is exceedingly difficult to make such code correct in multithreaded environment.
I am writing a server application in which there is a thread deployed to read/write many sockets connecting to clients. My manager tells me that it is not a good design, because if the thread aborts due to unknown reason then all the read/write work will stop forever.
So I wonder in what conditions will a thread abort, except the case we return from the Run() function of a thread. Do we need consider the case that the thread stops running abnormally?
It depends. One thread per client can be a bad thing scalability wise, especially if the thread doesn't do that much work per client. In that circumstance it can be better to have a thread that handles a number of clients, the idea to achieve a good balance between the number of threads and having them do a decent amount of work.
If on the other hand each thread is doing a lot of work per client then one thread isn't such a bad idea, the overhead of the thread not being significant in comparison to the work load.
So setting that aside, a thread will abort if your code is written so that the thread returns or self-terminates. If another thread in your program knows the thread's handle/id then the library you're using may have a function with a name like thread_kill(). That would allow that other thread to kill this thread, though that's almost always a bad idea.
So as far as I'm concerned your thread will only abort and disappear if you've written your code to make that happen deliberately.
Handling exceptions is probably best done in its entirety within the thread where the exception arose. I've never tried to do otherwise (still writing in pure C), but the word is that it's difficult to handle them outside the thread. Irrespective of whether each thread handles one or many clients you still have to handle all errors and events within thread.
It may be simpler to get that correct if you write I so that a thread handles handles a single client. Getting it wrong could lead to a thread getting into a stalled state (eg waiting for the client that is listening too) and accumulating those as time goes past will eventually kill your whole system.
I am writing a server application in which there is a thread deployed to read/write many sockets connecting to clients.
Not a good design. There should be at least one thread per client, in some circumstances two: one to read and one to write. If you're dealing in blocking I/O, servicing one client could block out all the others. (If you're dealing in non-blocking I/O you don't need threads at all.)
My manager tells me that it is not a good design, because if the thread aborts due to unknown reason then all the read/write work will stop forever.
He's right, for more reasons than he is advancing.
I have a QThread that fetches data from the web. Sometimes the user asks for something else, and the data needs to be fetched changes as well.
In my current configuration, I call terminate() upon the thread, change the input data, and call start() on the thread again. Now, that works fine, but sometimes I get the main eventloop stuck when calling isRunning() or isFinished() upon a terminated thread. It gets stuck forever, and does not recover until I kill the process.
Why would isRunning() or isFinished() hung in the first place? They don't suppose to block.
Is this workflow acceptable? If not, how can I stop a thread's process when I don't need it no more (or how can I abandon it)?
Don't use terminate(), read the warning in the documentation.
Whil it is possible to restart a QThread, restarting threads usually is not a good idea, there should be a better solution to do what you're trying to do.
It seems that in some cases, the thread becomes unusable after termination, and isRunning() and isFinished() may hang the calling thread, even if called only after the TERMINATED signal.
My workaround was to terminate a thread, forget about it and start a new one.
Question: I'm interested to know the best practice for killing a long standing operation that is running as a background thread (lets call this thread WorkerThread) in Java 1.2.
Scenario
Specifically, I'm developing an application for Blackberry devices whereby I make a HTTP connection. Big picture: a URL request if forwarded to a background thread (WorkerThread), the thread makes the request and returns the result using a call back.
Scenario Details
Now there exists a situation where at connection time, a data connection exists but then for whatever reason (drives through a tunnel) that connection no longer exists. Due to a limitation in Blackberry's design architecture, that actual connection will hang as the time out is fixed to be 2 minutes. As a result, there's a crucial need to kill a connection that has been hanging for a relatively (15 seconds) long period of time.
My Current Solution - 2 Theads?
Right now my current solution is to run WorkerThread inside another thread (lets call this new thread MonitorThead). MonitorThread starts WorkerThread, sleeps for 1000ms and then routinely checks if WorkerThread is still alive. If after 15 seconds WorkerThread is still alive, MonitorThread puts WorkerThread to sleep and exits. Is this really the best possible approach?
Summary of Question & Key points
In summary, below is the core question and key restraints associated with the question. Cheers!
How do I successful kill a java background thread that is stuck in a specific operation?
Scenario Restraints:
No control of having operation pause
and check the threads requested state
Specific to Blackberry's
implementation of Java ME 1.2 and its
Thread API so no explicit
kill() method
Most concerned about the best practice and how to
most safely kill a holding thread.
Follow Up/Edit
Neil Coffey recommended that I simply hold a reference to the connection object and instead call close() on that object. I am currently looking into this...
How to kill a Thread is a difficult question. There is no guaranteed way to be able to stop or interrupt a Thread. However, if you take your current architecture and upon timeout, just close the stream (not the Connection), that should cause an I/O Exception to occur on the thread that is stuck in I/O. If it doesn't cause an IOException, then it should at least cause the read or write to return with EOF.
Note that closing the Connection doesn't help, as the JavaDoc says:
Any open streams will cause the connection to be held open until
they themselves are closed.
You have to close the stream that was derived from the Connection.
Well, the best practice would normally be to get the connection to close, and then let the consequences of that ripple through to the thread, allowing it to exit cleanly.
How are you making the connection? Rather than waiting for it to time out, what are your chances of forcing it to close? Can you get hold of some connection object? Does the Blackberry have some other command that can be executed to kill a given connection?
I always believed that passing a flag into background thread in an atomic transaction has been the best way to ask a thread to stop. If it doesn't stop for a while, kill it.
Well, to add to that, if you believe 2 minutes is a long time, good for you. I'd let the user decide what's a long time with a cancel button.
I just implemented a thread pool like described here
Allen Bauer on thread pools
Very simple implementation, works fine, but my application no longer shuts down. Seems that two worker threads (and one other thread, I guess the queuing thread) stuck in the function
ntdll.ZwRemoveIoCompletion
I remember to have read something about IO completions in the help entry for QueueUserWorkItem (the WinAPI function used in the thread pool implementation), but I couldn't understand it properly. I used WT_EXECUTELONGFUNCTION for my worker threads since execution can take a while and I want a new worker thread created instead of waiting for the existing ones to finish. Some of the tasks assigned to the worker threads perform some I/O stuff. I tried to use WT_EXECUTEINIOTHREAD but it does not seem to help.
I should mention that the main thread waits for entry to a critical section witht the call stack being
System.Halt0, System.FinalizeUnits, Classes.Finalization, TThread.Destroy,
RtlEnterCriticalSection, RtlpWaitForCriticalSection
Any ideas what I'm doing wrong here? Thanks for your help in advance.
To make sure the worker threads shut down, you need to have some way of waking them up if they are waiting on the empty IO completion port. The simplest way would seem to be to post a NULL message of some kind to the port - they should then treat this as a signal to halt in an orderly fashion.
You must leave from the critical section before you can enter again. So the problem is inside a lock.
In some thread:
EnterCriticalSection(SomeCriticalSection);
sort code...
LeaveCriticalSection(SomeCriticalSection);
In some other thread:
EnterCriticalSection(SomeCriticalSection);
clean up code...
LeaveCriticalSection(SomeCriticalSection);
If the sort code is running in the first thread and the second thread try to run the clean up code the second thread will wait until the sort code finish and you leave the critical section. Only after leaving the critical section you can enter the same critical section. I hope this will help you narrow down the deadlock code because it is inside a critical section.
To get the completion port handle you can save it's handle when you create the completion port:
FIoCPHandle := CreateIoCompletionPort(INVALID_HANDLE_VALUE, 0 , 0, FNumberOfConcurrentThreads);
When using QueueUserWorkItem, as long as the worker threads have been returned to the thread pool, you should not have to do anything to shut them down. The WT_EXECUTEDEFAULT component of the thread pool queues the work items up onto an I/O completion port. This port is part of the thread pool's internal implementation and is not accessible to you.
Could you provide some more detailed call stacks for the threads that appear to be stuck? It would make this problem much easier to diagnose.