> Brilliant paper! Though it left me wondering about some stuff. I'm not so > used to the *nix platform in terms of what's happening inside. Though I do > understand the issues concerning SIGHUP etc.. and cross raising events > (signals). I had a quick look and evaluation on situations when this could > occur in win32 environment but ran into some question marks. Someone out There are many differencies in handling signals in Win32 ad *nixes. I must admit I do not know much about it in *nix but from Michal's article I understand (someone pls. correct me if I'm wrong), that function handling signal is called from the "external" process or thread. And this can result in multithreaded execution of the function, which can cause problems (unless function is aware of multithreaded execution). In Win32 you have much different issue: there are windows messages; and synchronization objects. None of them will put your code in thread you are not aware of (you did not created). - windows messages are processed in message pump, that you implement in your code. Messages are always delivered to thread which "owns" the window, which makes this solution perfectly suitable even for single-threaded apps. - synchronization objects can only be used by your thread to "wait" for the object to be released. You create other threads explicitly (Win32 CreateThread) which can share syncronization objects. Of course, if you created synchronization object available to other processes (it has to be named) and you did not protect it, some external process can take ownership of it, causing your thread to hang (if you used WaitForSingleObject(... , INFINITE) ). But anywat it will not put your code into another thread you are not aware of. Of course, things are much different with COM events - these are usually called by threaded created in RPC subsystem, or caller thread. But COM subsystem is aware of threading model your COM is designed to work for, and it will not put the same object executing in many threads if you set threading model to "single" . Windows device drivers is much different story, but I can't tell you much about it. You may want to read http://msdn.microsoft.com/library/default.asp?URL=/library/backgrnd/html/msd n_realtime.htm , but here's some part of the article: ---- When a device driver starts, the initialization routine will typically make the driver known to the system, register some entry points, and register an ISR. The device driver will wait, consuming only memory resources, until an interrupt occurs that meets the criteria of the driver's ISR; the driver's ISR is then entered. The driver will not be interrupted until the end of its interrupt service routine, unless a higher level-interrupt occurs. Unlike other operating systems, an ISR on Windows NT can be interrupted by another ISR with higher priority; this is one reason why interrupt latency is hard to define for Windows NT. When a driver is in its interrupt service routine, it should perform the minimum processing necessary to handle the interrupt, save the state necessary for processing the interrupt, queue a DPC routine for later processing that is not time-critical, and return. The DPC will occur at some later time-although it may occur immediately after leaving the interrupt service routine, if the system is not very busy. A DPC will run to the exclusion of all other processing (other than ISRs) until it exits. Most device driver processing is accomplished in this deferred processing routine or in even lower-priority routines queued by the DPC. --- (C) Microsoft 2001, article dated June 29, 1995 Regards B.
This archive was generated by hypermail 2b30 : Thu May 31 2001 - 14:03:23 PDT