mirror of
https://github.com/zeek/zeek.git
synced 2025-10-02 06:38:20 +00:00
Improve documentation for zeek_init event scheduling pitfalls
This commit is contained in:
parent
38af38beae
commit
d827e8b2d2
4 changed files with 10 additions and 6 deletions
4
CHANGES
4
CHANGES
|
@ -1,4 +1,8 @@
|
|||
|
||||
3.3.0-dev.390 | 2020-10-12 17:43:15 -0700
|
||||
|
||||
* Improve documentation for zeek_init event scheduling pitfalls (Jon Siwek, Corelight)
|
||||
|
||||
3.3.0-dev.388 | 2020-10-12 17:02:20 -0700
|
||||
|
||||
* Add CaptureLoss::Too_Little_Traffic notice (Vlad Grigorescu)
|
||||
|
|
2
VERSION
2
VERSION
|
@ -1 +1 @@
|
|||
3.3.0-dev.388
|
||||
3.3.0-dev.390
|
||||
|
|
2
doc
2
doc
|
@ -1 +1 @@
|
|||
Subproject commit ddec4e675013eff12746064fa4b6b723e86b5804
|
||||
Subproject commit 4f37431a116bd8951c5a63bb4d1e3ffb065152f4
|
|
@ -41,10 +41,10 @@
|
|||
##
|
||||
## When a ``zeek_init`` handler executes, Zeek has not yet seen any input
|
||||
## packets and therefore :zeek:id:`network_time` is not initialized yet. An
|
||||
## artifact of that is that any timer installed in a ``zeek_init`` handler
|
||||
## will fire immediately with the first packet. The standard way to work
|
||||
## around that is to ignore the first time the timer fires and immediately
|
||||
## reschedule.
|
||||
## artifact of that is that any timer installed in a ``zeek_init`` handler,
|
||||
## like with :zeek:keyword:`schedule`, will fire immediately with the first
|
||||
## packet. The standard way to work around that is to ignore the first time
|
||||
## the timer fires and immediately reschedule.
|
||||
##
|
||||
event zeek_init%(%);
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue