! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
xfce-spawn.c g_warning about setting marshaller twice
Status:
RESOLVED: WONTFIX
Product:
Libxfce4ui
Component:
General

Comments

Description dannym editbugs 2011-01-15 20:19:44 CET
When using the xfce_spawn* functions, there will be a runtime warning about setting the marshaller twice because in file xfce-spawn.c line 157 (i.e. within xfce_spawn_startup_watch()) there is code to set a hardcoded C marshaller for the GClosure. Short-term, I suggest to change it to:

if(G_CLOSURE_NEEDS_MARSHAL(spawn_data->closure))
      g_closure_set_marshal (spawn_data->closure, g_cclosure_marshal_VOID__INT);

... which should keep backwards compability with existing callers.

Long-term, I suggest to review the semantics of the file and ensure that setting a marshaller on a user-supplied closure is actually valid, i.e. whether GClosure is actually designed to be used that way.
Comment 1 dannym editbugs 2011-01-15 20:58:34 CET
The warning is:
"attempt to override closure->marshal (0xb6efe320) with new marshal (0xb7061520)"

It is emitted by glib-2.22.4/gobject/gclosure.c in g_closure_set_marshal.
if (closure->marshal && closure->marshal != marshal)
    g_warning ("attempt to override closure->marshal (%p) with new marshal (%p)",
               closure->marshal, marshal);
Comment 2 Nick Schermer editbugs 2011-01-15 21:06:56 CET
Let me explain why a closure was chosen:

The spawn function have an unidentified life time, they can last for a split second, but also for, say, 30 seconds. Because of that, a GObject setup (which is also a bit overdue). I'm quite sure there was also a discussion about that on ML at the time.

Because of that, the decision was made not to expose the structure (because that would imply an (un)ref mechanism or free) for a signal. A callback needs a _set function to unset it too (see below), but without returning structure this is not possible.

Now there was also a limited use of applications in core the needed to know when a spawn was finished; but if a spawn took too long, they were not interested in the callback anymore.

This is exactly what you can do with a closure; the spawn code can ref and trigger, the user can invalidate the close if its not required anymore.

Now the advantage for a callback or signal is that you can define a set of data you return, in this case the exit code. This a closure you can do with, but you sorta have to force a marshaller; so that's what we/I did.

Now you obviously only get the warning if you set the marshaller twice and we never do that, so its not entirely 'wrong', if works fine if you don't abuse it. So I wonder why you see this warning, because none is show in the code that uses it right now.

What we could do is, if the close has a marshaller we don't set it (like you suggested) and also not return the exit_code. I'm fine with that, but then the exit code is never made public.

Bug #7100

Reported by:
dannym
Reported on: 2011-01-15
Last modified on: 2012-02-20

People

Assignee:
Nick Schermer
CC List:
1 user

Version

Attachments

Additional information