C#巧用信號線程間通訊

以前有用過nodejs ,一開始很不習慣 Nodejs的事情驅動， 由於它的IO 無阻塞，習慣阻塞狀況下的編碼 ，無阻塞反而很納悶了。

在 nodejs IO雖然無阻塞的，致使文件，網絡通訊並非和C#同樣的執行方式，在nodejs中經過調用call back方法回調來完成一系列的調用。 習慣以後便會發現它的美妙了。好比在一個循環中，我要屢次發送請求，每次響應後，再接着發送。那麼在C#中很簡單，由於端口的監聽會阻塞住線程，直到接收到請求。因此只要發送新請求的代碼在接收以後執行，就行。 

然而，一樣的代碼邏輯在nodejs下就不行了，它的通訊不阻塞線程，因此，循環會在很短的時間內就跑完了，事實上，是在一時間內，將全部的請求全發送出去。並不能達到收到響應再發送下個請求的目的。  可是，能夠將下次請求放在callback中。這樣就保證了接收後再發送。這樣的事件驅動從思惟上講彷彿比C#更容易理解。

今天在程序中遇到一個頗有意思的地方。

static void Main(string[] args)
        {
            webSocket = new Client();
            // set event hander
            webSocket.ResponseEvent = ResponseHandler;
            webSocket.OpenEvent = OpenHandler;
            webSocket.CloseEvent = CloseHandler;
            webSocket.ErrorEvent = ErrorHandler;
            webSocket.MessageRecvEvent = MessageRecvHandler;

            manualEvent.Reset();
            manualEvent.WaitOne();
            Console.ReadKey();
        }

如上，若是沒有 manualEvent, 那麼主線程將會很快就執行完，而socket卻將來得及執行。這樣程序根本跑不起來。可是，我在主線程 經過manualEvent將主線程阻塞住，等待。 而在 soecket的 Reponse事件（異步的，在別的線程中執行）中 調用manualEvent的set方法，發送信號，讓主線程接着執行下去。

這一系列過程，很像 nodejs下的一個普通的socket了。不過，它的主線程（執行javascript的線程）在異步操做結束前， 彷佛並不會關閉，  否則這麼保證異步完成呢？ 這個有待考究。

 Any suggestions are welcome.