Frederick Virchanza Gotham <> wrote:
    > I think that there should be a page in the libpcap manual that
    > explicitly explains the multithreading capabilities and limitations.

okay, that sounds reasonable.
git clone

    > Some libraries have an entry in the manual stating that the library is
    > not threadsafe at all. Nine times out of ten, you're safe to use these
    > libraries from multiple threads so long as you use an exclusive lock.

I don't think that libpcap has been tested in this way.
I think it would work, and I don't think we use any thread local storage.

    > Some other libraries are thread-safe but the manual states that the
    > handle returned from the 'open' function can only be used by one
    > thread.

This is where libpcap is.

    > I remember seeing a page somewhere on the internet that read something
    > along the lines of: "The libpcap library is thread-safe, i.e. multiple
    > threads can call libpcap functions concurrently. However once you've
    > obtained a handle from pcap_open_live, that handle can only be used
    > exclusively by one thread -- with the exception of the pcap_breakloop
    > function".

I don't think we ever said this.

    > I think the debug build of libpcap should have runtime asserts to
    > ensure that the same thread is always operating on any given pcap_t*
    > handle. For example there could be a global map of pcap_t* handles to
    > thread ID's, something like:

    >     struct Mapping { pcap_t *handle; pthread_t thread_id; };

    >     Mapping mappings[32u];

I could tolerate this.

]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]        |   ruby on rails    [

tcpdump-workers mailing list --
To unsubscribe send an email to

Reply via email to