4 implement unblock stop logic for non ring source #10
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Turns out it's possible to use the
PPOLL
syscall without a ring buffer (i.e. without a mmap'ed memory area) as well by setting up the same event handling logic and executing theunix.Recvfrom
only upon receiving the appropriate event on the socket. This is obviously not "optimal" (in the sense of performance) becauseunix.Recvfrom
was already blocking / waiting for packets, but IMHO this is outweighed by the fact that the event file descriptor is the only way to reliably stop / unblock a blocked capture (needed for graceful stop and rotations in goProbe and maybe similar scenarios, and also to achieve feature parity with the ring buffer source).Given that the "plain" source is probably not the go-to choice for high-throughput situations anyway I think it's a good bargain. Should also help setting up a shared mock socket in #7 (because both sources now use the same socket / event logic).
Closes #4