Re: Threads
- From: Guy Harris <gharris flashcom net>
- To: david osoal org nz
- Cc: "Plonkowski, Piotr P SPOLSKA-IS/1" <Piotr P Plonkowski ope shell com>, "'GTK-list redhat com'" <GTK-list redhat com>
- Subject: Re: Threads
- Date: Tue, 12 Sep 2000 21:59:31 -0700
On Wed, Sep 13, 2000 at 04:51:19PM +1200, david osoal org nz wrote:
> Are you sure you need to use pthreads? I had a multiplexing problem with
> pcap which i solved by setting up a callback function (using
> g_io_channel_unix_new) for the listen file descriptor in the pcap
> structure (pcap->fd) for the read condition.
> Then when there is a packet to be read by pcap, the callback is called,
...or so one might think, had one not tried this on BSD. :-(
Unfortunately, "select()" on BPF devices doesn't work the way one might
want, at least if one sets a timeout on the BPF device (so that one can
get more than one packet per read, if traffic is heavy, which could be
important if there's a lot of traffic coming in). It only wakes up when
the BPF device's buffer fills, *not* when the timeout expires.
To handle that, one might set up a timeout and, when the timeout
expires, try reading from the pcap device. (Hopefully, O_NONBLOCK mode
works as one would hope on BPF devices; I've not yet tried it with
the GTK+-based sniffer program of which I'm one of the developers,
Ethereal - we currently handle multiplexing of libpcap and X
differently, in a fashion that doesn't quite work right in other ways.
We rely on the timeout causing the read to complete even if no packets
are available, and poll GTK+ for input when the read completes;
unfortunately, that doesn't work on some platforms, including Linux, so,
on Linux, we add a "select()" with a timeout before the read.)
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]