Alle 10:53, giovedì 26 ottobre 2006, Guy Harris ha scritto:
> frederic heem wrote:
> > Do you mean that on Solaris, when a read blocks and no packet arrives,
> > the read hangs forever ?
>
> Yes.
What about using select() + read() instead ?
>
> The purpose of the timer on Solaris is *NOT* to ensure that reads always
> complete within a fixed period of time. The purpose of the timer is to
> ensure that if packets are arriving slowly, a packet won't remain queued
> up and unread indefinitely.
>
> The pcap man page explicitly avoids making any claim that the timer will
> ensure that a read will complete within the timeout period.
>
> >> I.e., any code that depends on the timer preventing a read on a pcap_t
> >> from taking more than the specified amount of time is depending on
> >> something that libpcap does not and will not guarantee (and the libpcap
> >> man page explicitly indicates this). Does your code depend on that?
> >
> > Indeed, it depends on the fact that pcap_breakloop shall return in a time
> > which ha to be predictable. See other bug report about this subject:
> > https://sourceforge.net/tracker/index.php?func=detail&aid=1575387&group_i
> >d=53067&atid=469577
>
> The problem there is that there's no way for a pcap_breakloop() call in
> one thread to "poke" the descriptor/handle associated with a pcap_t to
> force it to return (other than to close it, but pcap_breakloop() is
> intended to leave the pcap_t usable; a reopen of the device, followed by
> a replacement of the descriptor in the pcap_t with the new descriptor,
> followed by a close of the original device, might achieve that, although
> that'd have to be done carefully to ensure it's thread-safe).
At the moment, the model is one thread per capture, each thread blocks in
capture_loop_start. The main program enters in the dbus loop waiting for some
request to process. When a client requires to close a capture, the server
calls pcap_breakloop(), hence capture_loop_start which is running in its own
thread returns, statistics can be computed and the capture can be really
closed.
The dbus loop thread does not call pcap_close() because the client may require
to get statistics, indeed, when a pcap handle is closed, it is too late to
get statistics. The other reason is to avoid calling pcap_close from
different threads.
With this architecture, the only thread issue is that the pcap handle variable
break_loop is not protected. One solution is to:
* add the private function _pcap_get_breakloop(pcap_t *) that returns
breakloop variable
* use it instead of directly poking the member.
* add a mutex in the pcap struture
* use it in pcap_breakloop() and _pcap_get_breakloop
>
> If you call pcap_breakloop() within a signal handler, and the signal is
> delivered to the thread reading from the descriptor, and the signal is
> set to interrupt system calls, pcap_breakloop() will work.
The dbus loop does not use UNIX signal because it's not portable to other
platform.
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
______________________________________________________________________________
--- NOTICE ---
CONFIDENTIALITY - This email and any attachments are confidential and are
intended for the addressee only. If you have received this message by
mistake, please contact us immediately and then delete the message from your
system. You must not copy, distribute, disclose or act upon the contents of
this email. Thank you.
PERSONAL DATA PROTECTION (Law by Decree 30.06.2003 n. 196) - Personal and
corporate data submitted will be used in a correct, transparent and lawful
manner. The data collected will be processed in paper or computerized form for
the performance of contractual and lawful obligations as well as for the
effective management of business relationship. Data may be disclosed, in Italy
or abroad, for the purpose above mentioned to third parties which cooperate
with Telsey, agents, banks, factoring companies, credit recovering companies,
credit insurance companies, professional and consultants, and shipping
companies. In relation to the same purposes, data may be processed by the
following classes of executors or processors: management; administration
department; logistics and purchase department; sales department; post sales
department quality department; R&D department; IT department; legal department.
The data processor is Telsey S.p.A. The data subject may exercise all the
rights set forth in art. 7 of Law by Decree 30.06.2003 n. 196 as reported in
in the following link http://www.telsey.it/privacy.jsp.
______________________________________________________________________________
798t8RfNa6Dl8Ilf
