我在做什么
我实施一个python / kqueue的基（FreeBSD的）溶液遵循的改变到一个特定的日志文件，其中，当所述KQ_NOTE_WRITE的fflag满足时，改变该文件是我Python脚本内拾起，并通过另一种功能处理的。
为什么我这样做
最终，我正在使用最新的日志文件条目并将其作为quick'n'dirty会计系统的一部分发送到其他地方。
我认为我需要知道
1）由于日志文件可以看到高流量的时段，我想知道是否会有任何“原子性”，即在将最新条目传递给日志文件时，我们会“错过”一个新条目进来吗？事实上，kqueue是一个“队列”，我没想到，但历史告诉我，我通常最终会觉得这样的假设是一个笨蛋。
2）kqueue是否可以保证为每个事件触发，或者多个事件可以通过？我想象的情况是几乎同时生成2个单独条目的日志文件。
感谢任何智慧/建议。
答案 0 :(得分：4)
你的怀疑是正确的。 ： - ）
如果在发生第二个相同事件时没有处于消耗过程中，则“扩展”kqueue“事件”。也就是说，假设低级别的事件序列是这样的：
1: you start monitoring the log file for writes
2: something writes to the log file (this adds a "write" notice to the kqueue)
3: your process is notified, but does not have a chance to go look yet
4: something (same something as step 2, or different, does not matter)
writes more to the log file (this merely "expands" the existing notice,
with no effect in this case)
5: your process finally gets a chance to read the "file was written" notice
from the kqueue
当第5步发生时，“文件被写入”通知将只是一个通知。由你的代码决定写出多少。例如，您可以使用fstat()在步骤1中检查文件的长度，然后在步骤5之后使用另一个fstat()。如果文件只是附加到，则这些点之间的大小差异是你关心的“新数据”。
请注意，如果您在步骤1中看到（比方说）100个字节，在步骤5之后看到500个字节，请执行步骤7：
7: you fstat the file
后来得到另一个“文件写入”通知，实际上可能存在“步骤6”，其中另一个写入文件。所以你应该为后来的步骤做好准备，找到添加了0个字节，即使你已经注意到添加了字节，因为在将注释附加到kqueue之后你可能已经读过它们了。
如果您正在查看syslog类型日志，请注意它们会在重命名文件时被“翻过”（然后有时会被压缩等）并创建一个新文件，例如“messages”就会变成“消息”创建了.0.bz2“和一个新的”消息“。您可以查看目录以及文件，并检查新文件创建，以捕获此类情况。