ronnie sahlberg wrote: > Feel free to reverse that change. > If time permits, I'll try to improve this. > It was part of an effort to start refactoring the code so that it > would eventually become possible to multithread wireshark, but the > work required to implement everything required is just too massive to > be realistic. >
Well, my feeling about this is that this goal is a huge amount of work - unrealistic for a single person - but maybe not unrealistic for the whole devel team. The requirements that arise from the horizon seems to be pointing in that direction: - loading multiple files into one Wireshark instance - make use of multitasking "Core" processors while loading capture files I would *love* to see this change, although I agree this will be a huge amount of work. In the background of the huge amount of dissectors we have nowadays, the only way to achieve this is to work step-by-step. 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. I don't know if there's enough motivation in the community to follow this approach - to bring this task to a real life ... Regards, ULFL _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
