I have an attached server thread blocked on an accept() waiting for connections. Externally I try to terminate the thread by calling pthread_cancel(), followed by pthread_join(). Upon calling the join, my program terminates with a SIGABRT.
I am, more than likely going to the detach the thread, and make it select() with a timeout to check for connections, so I can then "signal" it to quit. So, I know this is a solution, but being the curious type, I was wondering why the first solution doesn't work.
I think you're getting the program termination SIGABRT because of the pthread_cancel() -- when the blocked thread gets the signal, it probably dies. The signal delivery doesn't happen until after the call to pthread_cancel() has returned, so it just looks like it occurs because of the join call.
To check and see if my thoughts are right, I would insert a while(1); loop after the pthread_cancel() to see if you still get the SIGABRT.
Related
We are doing a simple timeout() call on a Flowable.
Flowable.fromCallable(() -> callToExternalService())
.timeout(500, TimeUnit.MILLISECONDS)
The timeout itself works fine, but we noticed that the timed out call callToExternalService, which sometimes could take minutes, even if it is discarded, doesn't free up the thread where it is running on, until it completes fully, and by doing so it's wasting resources. In our case, if the call times out, the thread can be killed straightaway, and so it shouldn't wait for the call to finish.
Is there a way to achieve this?
Add .subscribeOn(Schedulers.io()) (or some other scheduler) before the .timeout
I downloaded some interesting code from Indy 10 TIdTCPServer and compiled and ran it. It's a bit messy and it probably needs work but it's a good foundation for something interesting. At least I don't have to post all the code here. Anyway, I decided that the ExampleServer needs to be de-activated first, not just freed in OnDestroy. So I added:
procedure TServerPushExampleForm.FormClose(Sender: TObject);
begin
ExampleServer.Active := False; // bug here - never returns
end;
To try to debug this, I added IdCustomTCPServer.pas to the project and stepped into it.
An exception is raised in TIdCustomTCPServer.StopListening; at the line LListener.WaitFor; This exception is trapped in the exception handler in TIdListenerThread.Run; but the E.message isn't retrieved there, so I had to modify the code there to get the message:
"Operation Aborted"
I traced it further after that, but the code execution eventually comes back to the same exception handler.
Is this a bug or is it just better to never set the Active property to False? In my tests, if I close the app and let the RTL manage all the free'ing. The infinite loop doesn't occur (the app does actually close)
The exception is normal behavior.
Indy uses blocking sockets.
TIdListenerThread runs a loop waiting for clients to connect. Each wait is a blocking operation.
When the server is being deactivated, it closes its listening socket(s), causing pending socket operations to abort, and then the listening thread(s) are terminated. The abort exception is handled internally.
The server's destructor also sets Active=False, so whether you deactivate explicitly or not, the server will be deactivated.
This, in if itself, is not causing your hang. Typically, the only way setting Active=False can ever hang is if a server event handler tries to sync with the main UI thread synchronously while the main thread is blocked waiting for the server to deactivate. Classic deadlock scenario.
That does not appear to be the case in the demo you linked to, though (the only sync being used is asynchronous instead). So, something else is likely going on that your debugging hasn't reveiled yet. There should be no hang.
Is it possible to kill a thread that is locked due to a dispatch_sync? Here is the code:
dispatch_sync(q_, ^{
...
});
Here is the stack trace when it is locked:
#0 0x00007fff8d69951a in semaphore_wait_trap ()
#1 0x00007fff9aad7c5b in _os_semaphore_wait ()
#2 0x0000000100aec692 in _dispatch_barrier_sync_f_slow ()
I tried using pthread_kill but the thread does not terminate.
If you look through all the POSIX information, it is possible.
In reality, forget it. You'll never make it work. If you have a deadlock in your code, the only way to get rid of the deadlock is to fix your code.
BTW, a deadlock on an iOS device is much much worse than a crash. When an app crashes, many users don't even take any notice, they just start it again. When an app deadlocks, the user needs to use a much more complicated process to kill the app manually.
As a rule, I'd avoid dispatch_sync as much as possible.
pthread_kill() does not "kill" a thread in terms of ending it, it just sends it a signal.
The function of choice to (try to) end a thread is pthread_cancel().
Cancellation however only happpens when the code execution "passes" a cancellation point. The latter are well defined. See here for a list.
Can anyone help me??. I am trying to kill them, but, that will require a signal. So, I thought of using cancel.
Definitely pthread_cancel will not free the thread's stack, given that the canceled thread may continue to execute for some time, for example, executing cancellation handlers.
Thread resources are cleaned up after both pthread_detach were called on the thread and the thread has terminated (which is possible to occur in either order).
When does one use pthread_cancel and not pthread_kill?
I would use neither of those two but that's just personal preference.
Of the two, pthread_cancel is the safest for terminating a thread since the thread is only supposed to be affected when it has set its cancelability state to true using pthread_setcancelstate().
In other words, it shouldn't disappear while holding resources in a way that might cause deadlock. The pthread_kill() call sends a signal to the specific thread, and this is a way to affect a thread asynchronously for reasons other than cancelling it.
Most of my threads tends to be in loops doing work anyway and periodically checking flags to see if they should exit. That's mostly because I was raised in a world when pthread_kill() was dangerous and pthread_cancel() didn't exist.
I subscribe to the theory that each thread should totally control its own resources, including its execution lifetime. I've always found that to be the best way to avoid deadlock. To that end, I simply use mutexes for communication between threads (I've rarely found a need for true asynchronous communication) and a flag variable for termination.
You can not "kill" a thread with pthread_kill(). If you try to send SIGTERM or SIGKILL to a thread with pthread_kill(), it will terminate the entire process.
I subscribe to the theory that the PROGRAMMER and not the THREAD (nor the API designers) should totally control its own software in all aspects, including which threads cancel which.
I once worked in a firm where we developed a server that used a pool of worker threads and one special master thread that had the responsibility to create, suspend, resume and terminate the worker threads at any time it wanted. Of course the threads used some sort of synchronization, but it was of our design and not some API-enforced dogmas. The system worked very well and efficiently!
This was under Windows. Then I tried to port it for Linux and I stumbled at the pthreads' stupid "theories" about how wrong it is to suspend another thread etc. So I had to abandon pthreads and directly use the native Linux system calls (clone()) to implement the threads for our server.