> I have a question about the block of pcap_dispatch(). When pcap_dispatch is
> blocked in the time specified by pcap_open_live(), a signal is delivery to it
> and the signal handler is invoked and then return,
> 1) Will the blocked pcap_dispatch() be interrupted?
> 2) If the blocked pcap_dispatch() is interrupted, will the errno be set to
> EINTR?
The answer to both of these questions may depend on the OS you're using,
but:
1) In "pcap-dlpi.c", which is used on SunOS 5.x, HP-UX, and,
optionally, AIX (and possibly other systems), if the
"getmsg()", which is the call that will actually be
interrupted, returns -1 and sets "errno" to EINTR (which is
what will happen if a signal arrives), "pcap_read()" will
just continue, rather than returning -1.
2) "pcap-bpf.c", which is used on BSD and, optionally, AIX
(although the BPF mechanism in AIX is unsupported and
somewhat non-standard, so you probably shouldn't use it on
AIX), also just continues in "pcap_read()" on EINTR.
3) "pcap-snit.c", which is used in SunOS 4.x, *doesn't* continue
on EINTR, it just returns -1. Thus, *if* a "read()" on a
STREAMS device returns -1 and sets "errno" to EINTR when a
signal arrives, then "pcap_dispatch()" will be interrupted
and "errno" will be set to EINTR.
However, I don't remember whether that'll happen by default;
it may be that, even on STREAMS devices, a signal will, by
default, restart system calls rather than interrupting them.
I forget the call you'd make to cause a signal to interrupt
system calls.
4) "pcap-linux.c" also continues on EINTR.
5) So does "pcap-snoop.c", used on IRIX.
6) However, "pcap-pf.c", used on Digital UNIX, doesn't.
7) Neither does "pcap-nit.c", used on SunOS prior to 4.x.
So the answer appears to be "it depends".
The rationale for continuing on EINTR, at least in "pcap-dlpi.c" and
"pcap-bpf.c", is to keep libpcap from "chok[ing] when we get ptraced"; I
don't know what the problem is there.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
