LEGO wrote:
On 5/28/05, Joerg Mayer <jmayer@xxxxxxxxx> wrote:
Yes, Ethereal (and especially libethereal) is not threadsave and it will
be lots of work to make it that. We want to get there eventually, but
it may take a long time until we actually do. You are free to speed up
that process of course ;-)
A lot to do:
- tvb_* and proto_tem_* should use a thread safe memory allocation mechanism
- every dissector needs:
- a container that contains its current static variables
- a constructor for it
- a destructor for it
- replace g_malloc and its clients (printfs too) with something thread safe.
The issue is less one of thread safety than, as Ulf noted, an issue of
"more than one capture file open at the same time" safety.
An application linked against libethereal can have one capture file
open, but it can't have more than one capture file open, as the state
information kept by dissectors is global, rather than per-capture file.
The "more than one capture file open at the same time" safety *might* be
somewhat usefully solved without also solving the "thread safety"
issue, although if you do that a time-consuming operation (such as
filtering) running on one open file would stall operations on other
files unless some amount of task multiplexing were done, but, well, most
modern OSes can do that multiplexing for you (although, for example, the
user-land threading packages in older BSDs would have difficulty
multiplexing capturing with other operations, as "select()" doesn't work
on BPF devices in older BSDs). To do that the containers would be
attached to a capture_file structure, with that structure either passed
directly to dissectors or passed through a pointer in the packet_info
structure.
That *alone* would probably be a significant task, so it probably won't
happen in the short term, possibly not even in the medium term.