Sebastien Tandel wrote:
As almost every dissector will be involved, the only realistic approach
in my eyes would be an approach I would call "blooming". The "changed"
dissectors will exist for a long time in parallel to the "old"
dissectors. The "blooming" approach means we'll have to "bloom" from the
bottom to the top (e.g. Ethernet to HTTP) - while the Ethernet dissector
is already thread safe, the upper IP/TCP/HTTP dissectors are still "old
style".
This means the supporting libraries will have to have two sets of API
calls, the new thread safe and the old "classic" one.
Don't you think it could be better to create a new branch in the svn and
create a long term project?
We could begin this project by inserting a minimal set of dissectors
(and therefore eliminating some of the useless dependencies between some
dissectors) in the new svn branch. Then modify them to be thread-safe.
Once this is done we can continue by adding the others dissectors one by
one into the new branch and modify them.
Of course it requires some extra work to integrate the future patches
coming for the main branch but, IMHO, it would be cleaner.
Given the volume of changes going into the trunk and the length of time
it would likely take to parallelize Wireshark, I would think that a
parallel trunk would get way too far out of sync to be useful. That and
I hate merging. (But then again, I'm not a developer by profession so
I'm not used to it...)