I have a program that have 2 threads running at the same time. Every method is surrounded with a try and catch. If one of the threads creates an exception will it stop the other thread from working as well?
Thanks
No. It will only stop the current thread. The other thread will continue working.
Exceptions are being stored in the stack of each thread.
You can pass exception information between threads using asynchronous delegates:
Catching an exception thrown in an asynchronous callback
Related
I guess it's the thread, say A, on which the timer was created. But I can't figure out how exactly the callback function is called. Assume the timer expires, and then what happens? Does this happen when this thread gets its time slice? And if this is the case, I think the function should be called by the scheduler or what before the context is finally switched to A, then can I say A is the caller?
Thanks.
The timer callback can also be called by a pool thread, a thread that specifically manages timers or in the context of the creating thread, (the creating thread is designed to accept and process an 'Asynchronous Procedure Call'). The flag paramters in CTQT() control the action upon timer expiry.
If the timer event is called by a pool thread or timer-manager thread, that thread will become ready upon expiry and, when there is a core available to run it, it will make the callback 'immediately' within its own context. The thread that created the timer could, if it wished, wait on a synchro object, (event or semaphore), that could be signaled by the timer callback, (ie. normal inter-thread comms).
The timer callback can only be executed in the context of the thread that created it if that thread is in a position to execute the callback when it receives some sort of signal. In the case of these timers, an APC is QUEUED to the creating thread and, if that thread is blocked on one of the 'alertable' wait calls, it will become ready immediately, will run when there is a core available to run it. After the APC has run, the wait call will return. If the wait call is not SleepEx(), it will return WAIT_IO_COMPLETION - a result that is usually ignored. If the thread is not waiting when the APC is queued up, it will not be executed until the thread makes the next wait call, (obviously - since the thread must be off doing something else:).
'And if this is the case, I think the function should be called by the scheduler or what before the context is finally switched to A, then can I say A is the caller?' NO!
When a TThread enters in Synchronized() method, it waits until EnterCriticalSection(ThreadLock) returns.
Now, which one will run the method if in the meantime, another Tthread, or even the main thread call some method of the waiting Tthread?
What could happen if in the meantime, another thread, or even the main thread call some method of the waiting thread?
Threads do not have methods, so this question is a non-sequitur.
It is not meaningful to ask what happens when you call a method of another thread. Because it is not possible to do so. When you call a method, that method executes on thread which called it.
A method like TThread.Synchronize schedules the execution of code onto a different thread. But, the body of TThread.Synchronize is executed by the thread of the caller.
A call to EnterCriticalSection cannot be interrupted by user mode code. So, suppose that thread A calls EnterCriticalSection at a point where thread B holds the lock. The call to EnterCriticalSection made on thread A will not return until thread B has released the lock. While thread A is blocked waiting to acquire the lock, no code will execute on thread A.
It seems, from clarifications in the comments, that your question is in fact:
When a method of TThread is called, on which thread does that method execute?
The answer is that the method is executed on the calling thread. There's nothing special about the TThread class and so the normal rules apply.
Say I have an #Async method call that hangs. Will it time out? What is best practise here to free you resources?
#Async method invocations are executed within a specified thread pool. If your method hangs, it will hold one thread from the pool infinitely. Spring can't do anything about it.
If your method is kind enough to accept InterruptedException, you can cancel it by calling Future.cancel() on a value returned from asynchronous method.
When I spawn a thread with Thread.new{} it looks like any exception that happens in that thread never sees the light of day, and the app just quietly ignores it
Normally, threads are isolated from each other, so exception in one won't terminate the whole application.
But, although I never used them, Thread class has several abort_on_exception methods, even with some examples. They should do what you want.
http://corelib.rubyonrails.org/classes/Thread.html
Adding to Nikita's answer, you can also trigger the exception by calling thread.join on the thread you've generated.
If you run the program with the debug flag on (ruby -d), then you'll also abort when an unhandled exception is raised in a thread.
I've read the documentation for ReadDirectoryChangesW() and also seen the CDirectoryChangeWatcher project, but neither say why one would want to call it asynchronously. I understand that the current thread will not block, but, at least for the CDirectoryChangeWatcher code that uses a completion port, when it calls GetQueuedCompletionStatus(), that thread blocks anyway (if there are no changes).
So if I call ReadDirectoryChangesW() synchronously in a separate thread in the first place that I don't care if it blocks, why would I ever want to call ReadDirectoryChangesW() asynchronously?
When you call it asynchronously, you have more control over which thread does the waiting. It also allows you to have a single thread wait for multiple things, such as a directory change, an event, and a message. Finally, even if you're doing the waiting in the same thread that set up the watch in the first place, it gives you control over how long you're willing to wait. GetQueuedCompletionStatus has a timeout parameter that ReadDirectoryChangesW doesn't offer by itself.
You would call ReadDirectoryChangesW such that it returns its results asynchronously if you ever needed the calling thread to not block. A tautology, but the truth.
Candidates for such threads: the UI thread & any thread that is solely responsible for servicing a number of resources (Sockets, any sort of IPC, independent files, etc.).
Not being familiar with the project, I'd guess the CDirectoryChangeWatcher doesn't care if its worker thread blocks. Generally, that's the nature of worker threads.
I tried using ReadDirectoryChanges in a worker thread synchronously, and guess what, it blocked so that the thread wouldn't exit by itself at the program exit.
So if you don't want to use evil things like TerminateThread, you should use asynchronous calls.