[frederic heem <frederic.heem@xxxxxxxxx>]

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