--- Begin Message ---
On Fri, May 20, 2022 at 6:10 PM Bill Fenner <fen...@gmail.com> wrote:
> On Fri, May 20, 2022 at 12:36 PM Guy Harris <ghar...@sonic.net> wrote:
>
>> If it's putting them in non-blocking mode, and using some
>> select/poll/epoll/etc. mechanism in a single event loop, then the right
>> name for the API is pcap_setnonblock(). There's no need for an eventfd to
>> wake up the blocking poll() if there *is* no blocking poll(), so:
>>
>> if non-blocking mode is on before pcap_activate() is called, no
>> eventfd should be opened, and poll_breakloop_fd should be set to -1;
>>
>> if non-blocking mode is turned on after pcap_activate() is
>> called, the eventfd should be closed, and poll_breakloop_fd should be set
>> to -1;
>>
>> if non-blocking mode is turned *off* afterwards, an eventfd
>> should be opened, and poll_breakloop_fd should be set to it;
>>
>> if poll_breakloop_fd is -1, the poll() should only wait on the
>> socket FD;
>>
>> so this can be handled without API changes.
>>
>
> Thank you for the excellent observation, Guy. It is indeed setting
> non-block before pcap_activate(). I'll work on this plan.
>
Actually, I confused myself. It turns out that pcap_linux is buggy when
you set non-block before pcap_activate() -- it uses the handlep->timeout
value to remember whether or not non-block was set, but, pcap_activate()
unconditionally overwrites handlep->timeout. So it just comes down to, for
now, we always open the eventfd and then can close it when non-blocking
mode is turned on. This just means the first item on your list is not
done, but the last 3 are enough.
(I think that the right fix for setting nonblock before activate could be
to add a bool to the handlep, to separate the nonblock status from the
timeout, but that can be a separate fix.)
Bill
--- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
