i'll edit this post from time to time to update it untill it's finished.
Worker Thread and Service Agent execution.
If an exception is thrown from the SA, the exceeption is logged (using the Exception management mechanism). The default exception publisher logs to System Event log.
This is because the worker thread has a try-catch inside the thread proc. And this makes that the while loop inside the thread procedure to continue.
The Worker thread has a serviceAgentRequest memeber variable which is set \ cleared to null on SA creation execution \ SA execution returns.
Worker thred checks for this variable at the loop begin and resubmits the request (it wont look at the requests queue).
So, when an exception is thrown from a SA during execution, the SA will be resubmitted indefinetely until the SAMonitor aborts the worker thread.
Regarding the SAMonitor: Note that in the case of the exeception thrown from SA, the SAMonitor is called to add the worker thread at each resubmission. But SAMonitor checks if it has that worker thread already in its thread table and removes it and adds it again.
So this means that if a SA exception appears you can decide to either rethrow the exception so the request is resubmit or not rethrow it and maybe just return from execution (and the worker thread will mark the request as completed).
Wednesday, July 25, 2007
Sunday, July 15, 2007
Opening CHM Help files from Network or Internet
Due to a security patch Windows has restricted access to a CHM. More info here: http://support.microsoft.com/kb/896358.
The attached reg script fixes one of the 4 problems described in the KB. It works for most of the CHM files. Here is the file.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"MaxAllowedZone"=dword:00000004
The attached reg script fixes one of the 4 problems described in the KB. It works for most of the CHM files. Here is the file.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"MaxAllowedZone"=dword:00000004
Monday, July 09, 2007
Win32 HANDLEs
Each time when you use a win32 API which uses a HANDLE remember that the handle Must be valid (not closed).
It is important to understand the concepts of the handle being signaled and being closed.
Signaled state refers to the handle state. It can be signaled or unsignaled. Wait functions for example, like WaitForSingleObject, block current thread until the object gets signaled.
A handle is said to be closed when its reference count reaches zero value. When this happens the handle is closed and doing any waiting on it is error prone.
A handle is a pointer on an object. Wait functions check the state of the object, hence it is a must that the handler (the pointer) is valid. Otherwise, waiting functions wont work properly (while waiting on an invalid handle, you might wait indefinetly).
One example of bogus use is with MFC AfxBeginThread function. Its default behaviour is to auto 'delete' the thread, i.e to close its handle.
Its bad to use the returned handle after the thread is terminated and closed.
That its not a HANDLE. its a wild HANDLE.
This is described excellent in Chapter 12, Threads in the well known book by Jeff Prosise, Programming Windows with MFC, 2nd Edition.
Another missuse, without MFC, might be in an multithreaded application. One threads create a thread and share the handle others thread which use it.
It is important to understand the concepts of the handle being signaled and being closed.
Signaled state refers to the handle state. It can be signaled or unsignaled. Wait functions for example, like WaitForSingleObject, block current thread until the object gets signaled.
A handle is said to be closed when its reference count reaches zero value. When this happens the handle is closed and doing any waiting on it is error prone.
A handle is a pointer on an object. Wait functions check the state of the object, hence it is a must that the handler (the pointer) is valid. Otherwise, waiting functions wont work properly (while waiting on an invalid handle, you might wait indefinetly).
One example of bogus use is with MFC AfxBeginThread function. Its default behaviour is to auto 'delete' the thread, i.e to close its handle.
Its bad to use the returned handle after the thread is terminated and closed.
That its not a HANDLE. its a wild HANDLE.
This is described excellent in Chapter 12, Threads in the well known book by Jeff Prosise, Programming Windows with MFC, 2nd Edition.
Another missuse, without MFC, might be in an multithreaded application. One threads create a thread and share the handle others thread which use it.
Labels:
handle,
multithreading,
synchronization,
win32api
Subscribe to:
Posts (Atom)