[Jim Wright <James.R.Wright@xxxxxxxxxxxx>]

Jakub, sorry about the global variable. The recent work on packet-dtn.[ch] comes from me. I read all the wireshark developer info prior to diving in, but I admit I don't recall any particular discussion of this. As you can see from [1], there were a great many global variables in there prior to my work. I just assumed that was the way to do it, and yet I still agonized over how to most effectively get the "bundle_custodian" variable into the code. I agree that global variables are to be avoided.

Do you have particular suggestions? Are some of the global variables here "less offensive" than others?

Jim

Jim Wright

BioServe Space Technologies

james.r.wright@xxxxxxxxxxxx

303-492-1579

On May 8, 2012, at 4:26 PM, Jakub Zawadzki wrote:

Hi,

What's current policy of using global variables in dissectors?
Some time ago I've fixed some issues connected with storing ep_ memory in
global variables: r42002, r42005, r42008 and prepared patch for bug #7060

And I'm *really* not happy when we add it, like recent commit to packet-dtn.c [1]
This commit seems safe, but I'd prefer to ban using global variables to store
any information about current dissection.

AFAIK we also plan to have libwireshark thread-safe.
We can use TLS support in glib (GStaticPrivate[2]) or
what compilers offers like __thread in GCC[3] or __declspec(thread) in MSVC[4]
or even mutex for whole protocol dissection
but wouldn't be better to not use global variables?

There's already packet_info structure which is always private for current
dissection. The easiest fix would be to move all global variables
to packet_info structure. Anyone against it?


[1] http://anonsvn.wireshark.org/viewvc/trunk/epan/dissectors/packet-dtn.c?r1=42507&r2=42506&pathrev=42507
[2] http://developer.gnome.org/glib/2.30/glib-Threads.html#GStaticPrivate
[3] http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Thread-Local.html
[4] http://msdn.microsoft.com/en-us/library/6yh4a9k1.aspx
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe