Hello,
Franck Joncourt wrote:
> Hi Sébastien,
>> We have been without news since about 2 weeks.
Sorry for being slow to answer. From time to time, even I can be
catch back by real life things.
> What about this bug?
I didn't forget about this bug, your mails are the last ones in my
inbox (I'm using an inbox-zero process).
> Have you been able to reproduce the problem?
I also tried without success on my machine at work, an x86-64 running
an old Mandriva system, with Net::Pcap 0.16, libpcap 0.9.1. This bug
seems to be either very tied to the x86 or to a recent version
version of the libpcap.
I've also tried and failed to link Net::Pcap with libpcap 1.0.0,
which is problematic.
> Do you intend to update libnet-pcap-perl?
I intend to update Net::Pcap.
> Should we patch libnet-pcap-perl in order to remove the ability to be
> interrupted by a signal for this release?
I've answered Martín's concerns in the CPAN-RT ticket:
> I'd say many Perl users don't know how signals are actually
> handled. In fact, more than a few are surprised that signals are
> not immediately delivered. IIRC, I added this code to Net::Pcap
> because I had a couple of requests (by private mail, not on CPAN-
> RT) to modify Net::Pcap so it behaves this way.
>> I also remember explaining this to a couple of colleagues, and how
> to enable "unsafe" signals.
So, as you already suggested..
> I think maybe that could be nice to have a way to enable/disable the
> current behavior of the pcap_loop function against interrupts.
.. I'll add a new function, pcap_perl_settings() to address this
particular issue.
> Having a note about the possible problem would also be good as Martin
> pointed out.
I'll add a note about signals, pointing to the pcap_perl_settings()
function.
I'll also have to fix the problems with libpcap 1.0.0
--
Sébastien Aperghis-Tramoni
Close the world, txEn eht nepO.