本来不想写这个blog的，因为估计没有读者。不过想想反正也就几个朋友在看，写写也无妨。
最近在用Event Tracing for Windows (简称ETW) 做Longhorn里resource cache loader和resource cache service之间的通讯。不知道ETW这个东东MS外面的人用的多不多？Anyway，从我使用的经验来讲，觉得这是一个不错的IPC方法，至少除了Named Pipe之外，你还有另一种选择（shared memory map当然也可以，但我的意思是那种有点像网络通讯的传递方式）。
ETW主要包括3个component：Controller, Provider, and Consumer. 这3个的角色从名字一看就清楚了。我简单介绍一下使用的方法：
Provider首先应该用RegisterTraceGuids注册一个Event Trace，同时提供给RegisterTraceGuids的还有一个ControlCallback，这个callback在Provider被Controller启动（enable）和停止（disable）的时候会被调用，然后Provider就可以相应地开始用TraceEvent来发送Event Trace或者停止发送。当然，Provider还要通过这个callback的一个参数来了解应该往哪里送trace，这个参数就是一个由Controller打开的event trace session。什么是event trace session？往下看
Controller的主要任务有两个：一是用StartTrace在内存中创建一个event trace session，这样Provider就知道该往哪里送trace，而Controller也会负责将session里记录的trace送到Consumer手里。Controller的第二个任务就是启动（API: EnableTrace）和停止（API: ControlTrace）Provider。为了避免额外的开销，Provider不会一直都在工作，只有当被Enable的时候，才开始工作（注：其实这么说是不正确的，Provider其实是不必收Controller控制的，它可以随时随地发送trace，只要它知道那个event trace session的句柄，这完全取决于Provider具体是怎么写的。但在实际操作上，Provider都是根据Controller的Enable/Disable信号来启动和停止tracing的。我自己写的一个snippet program是这样，其他现有的正规的Provider也是这样。）
第三个是Consumer，Consumer主要做这几件事：1. 用OpenTrace打开和event trace session之间的通道。2. 设计event trace callback，你可以设计一个generic的callback用来handle所有的event trace，不管是不是你感兴趣的。你也可以为特定的event trace设计callback，专门处理你关心的trace。Generic的callback实在OpenTrace的时候在参数中指定的，而特定的callback可以用SetTraceCallback来注册。3. 调用ProcessTrace，开始处理Trace。注意，这里有一个很tricky的地方：ProcessTrace是block的！就是说ProcessTrace不会返回，除非Controller结束这个session或者Consumer自己调用CloseTrace（注：CloseTrace只有在Longhorn可以使ProcessTrace返回，XP不行）。呵呵，那你问了，ProcessTrace都不返回，我的Consumer还怎么调用CloseTrace啊？答案很简单：你需要第二个线程，那个线程什么也没干，就调用了ProcessTrace，然后它就待在那里，直到Consumer的主线程调用CloseTrace或者Controller关闭了整个session。我知道这个方法很奇怪，但，不要问我，这是ETW team给我的答案，他们肯定有他们的考虑。
最后想说的是：很多时候你会发现，Controller和Consumer都是在一个program里的。这个很好理解，Provider都在场面上了，你要用它们发送的trace来取得信息，你的程序当然会既做Controller (打开session，启动Provider)又做Consumer。
