Re: widget's signal callback: inside gdk lock?

[Tristan Van Berkom <tvb gnome org>]

Felix Kater wrote:
[...]
> a. The lock is already aquired by gtk when the button is toggled by
> the user's mouse click--so the callback is already (automatically)
> inside the lock from the client programmer's view.
>
> b. The lock has to be aquired explicitly by the client programmer who
> is using gtk (in case she wants to access other gtk stuff savely).

Hmmm,
    this is always hard to explain; lets take a look at the different
api's and perspectives in GTK+:

    - GTK+ API, includes gtk_toggle_button_toggled(),
      gtk_button_clicked() and many many more, notably
      gtk_widget_event(), gtk_widget_event() is part of the
      GTK+ api (therefore the lock must be held to call it), its
      job is to interpret a GDK event into a GTK+ event signal
      (those event signals may in turn, recursivly emit widget
      signals, like GtkButton's "clicked" as a result of
      "button-release-event").

    - The GTK+ Application, accesses the GTK+ API and must aquire
      the lock when calling the API.

    - The GTK+ "Core", i.e.; the guts of gtk_main(), the mainloop
      processing code has the same perspective as the GTK+ Application,
      the core code will wait for incomming GDK events and call
      gtk_widget_event() on the correct GtkWidgets... but not without
      aquiring the lock first.

So the simplified answer is: If the signal is part of the GTK/GDK api,
you are running *inside* the lock, regardless if it was your app or
the GTK+ core that accessed the GTK+ api, either/or were responsable
for aquiring the lock.

Cheers,
                             -Tristan