Since signal names are the same as property names, reference between the
two. Improve the formatting, and make it clearer that `_` is
discouraged.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #358
This uses a 32bit hole in the GObject structure on 64bit arches
as a flag field which can be optionally used for some preformance hints.
Currently there is a flag that gets set any time you connect to a signal
on a GObject which is used as early bailout for signal emissions, and using
the flags field instead of a user-data for checking if a GObject is
under construction.
If we specify a c_marshaller, g_signal_newv() will never assign an
va_marshaller automatically. So either use NULL (for simple cases), or
specify both to avoid the generic performance penalty.
It allows to disconnect a signal handler from GObject instance and at the same
time to nullify the signal handler.
Provided also a macro for handler type conversion.
It's theoretically possible that we could have a case where this would
actually return NULL, but it's difficult to imagine a valid program that
would contain such a case.
Add an explicit assert here to quiet up static analysis.
See the bug for more discussion.
Coverity CID: 1159477
https://bugzilla.gnome.org/show_bug.cgi?id=730296
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
gtk-doc doesn’t make the return type clear, because these are macros
rather than inline functions, so people often have to guess at the
return type (or look it up from g_signal_connect_closure(), but that’s
hard work).
Make it clear that the return type for handler IDs is gulong. While
there, fix the capitalisation of ‘id’ to ‘ID’ in a few places.
Add various (nullable) and (optional) annotations which were missing
from a variety of functions. Also port a couple of existing (allow-none)
annotations in the same files to use (nullable) and (optional) as
appropriate instead.
Secondly, add various (not nullable) annotations as needed by the new
default in gobject-introspection of marking gpointers as (nullable). See
https://bugzilla.gnome.org/show_bug.cgi?id=729660.
This includes adding some stub documentation comments for the
assertion macro error functions, which weren’t previously documented.
The new comments are purely to allow for annotations, and hence are
marked as (skip) to prevent the symbols appearing in the GIR file.
https://bugzilla.gnome.org/show_bug.cgi?id=719966
This is almost always what you want, because if you're using this you
want to know if any "custom code" (i.e. not the default class closure)
is going to be run if you emit this signal.
I looked at all the existing uses of this and they were all broken in the
presence of g_signal_override_class_closure().
https://bugzilla.gnome.org/show_bug.cgi?id=754986
It’s quite common to see naked g_signal_connect() calls without a paired
g_signal_handler_disconnect(). This is commonly a bug which could lead
to uses of the callback user data after it’s been freed.
Document the best practices for avoiding this kind of bug by properly
disconnecting all signal handlers.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
Add a global lookup table for signal handlers. We already give
them a unique ID, so there is no good reason to pay for
non-constant lookups when disconnecting handlers.
https://bugzilla.gnome.org/show_bug.cgi?id=737009
Used for the commonly used case (in signal emission) where we
initialize and set a GValue for an instance
Includes a fast-path for GObject
Overall makes it 6 times faster than the previous combination
of g_value_init + g_value_set_instance
Makes signal emission around 10% faster
https://bugzilla.gnome.org/show_bug.cgi?id=731950
- GSubprocessLauncher exists since 2.40, not 2.36
- more logical order for g_markup functions
- fix short description of GMarkup
- GMarkupParser: specify that some parameters are NULL-terminated.
- g_string_new (NULL); is possible.
- other trivial fixes.
https://bugzilla.gnome.org/show_bug.cgi?id=728983
We previously hold a lock in the loop that collects the arguments for
g_signal_emit(), which we drop before calling into the argument
collection functions and reacquire again at the bottom of the loop (ie:
one release/acquire pair for each argument collected). To make matters
worse, the lock is just released again after the loop.
Presumably that was done to protect the access to the parameter array,
but it's pretty unlikely that this is needed because the only way it
changes is if the signal is unloaded. That only happens when unloading
types which is quite unlikely to happen while we are emitting on an
instance of that type (and, as an aside, never happens anymore anyway).
If we move the unlock below the loop up above it and remove the
acquire/release pair from the loop, we improve performance in the new
arg-collecting performance tests by ~15% (more like ~18% in the case
where we only emit to one handler -- where argument collection dominates
more).
https://bugzilla.gnome.org/show_bug.cgi?id=694380
Back in the far-off twentieth century, it was normal on unix
workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
APOSTROPHE to be drawn as "’". This led to the convention of using
them as poor-man's ‛smart quotes’ in ASCII-only text.
However, "'" is now universally drawn as a vertical line, and "`" at a
45-degree angle, making them an `odd couple' when used together.
Unfortunately, there are lots of very old strings in glib, and also
lots of new strings in which people have kept up the old tradition,
perhaps entirely unaware that it used to not look stupid.
Fix this by just using 'dumb quotes' everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=700746
When looking up signals by name (to connect, for example) and the named
signal cannot be found on the given instance, report the type of the
instance.
This is quite a lot more useful as a diagnostic message than only a
memory address.
https://bugzilla.gnome.org/show_bug.cgi?id=694350
We need to keep a reference to the handler in the fast path, just like
in the slow path, otherwise if another thread disconnects the handler
we may destroy the closure while we're using it without the lock held.
We also move the freeing of the instance to after the emission is totally
done as the handler_unref_R (and the tracepoint) reference it.
https://bugzilla.gnome.org/show_bug.cgi?id=694253
handler_ref and handler_unref_R are always called with the signal
lock held. This is obvious for handler_unref_R as it even sometimes
drops this lock, and can be verified quickly for handler_ref by looking
at all call sites.
This improves the performace about 6% on the emit-handled and the
emit-handled-generic tests.
https://bugzilla.gnome.org/show_bug.cgi?id=694253
This is the bug that has been causing segfaults and criticals when accel
keys are used to close windows via GtkUIManager.
The main cause of this problem was a mistake made in the original patch
when modifying the handler_lookup() to take the extra 'closure'
parameter. The original check used was:
if (handler->sequential_number == handler_id ||
(closure && handler->closure == closure))
It was called to find a particular closure like so:
handler_lookup (instance, 0, closure, &signal_id);
The problem is that the check will return if either the signal ID or
closure matches (if a closure was given). The calling code assumes 0 to
be an invalid signal ID which will match no handlers, but unfortunately
the rest of gsignal code uses this to denote a signal that has already
been disconnected. The result is that this function was searching for a
matching closure _or_ the first already-disconnected handler. When it
found the already-disconnected handler, we'd get criticals and crashes.
The condition has been corrected; it now ignores the handler_id
parameter if the closure parameter is non-NULL.
While we're in here, change the lifecycle of the invalidation notify to
be easier to understand.
Before, the notify was removed when the last reference on the handler
dropped. This could happen in very many situations; often at the end of
an emission. Instead, we now tie the registration of the notifier to
the lifecycle of the signal connection. When the signal is disconnected
we remove the notification, even if other references are held (eg:
because it is currently being dispatched).
https://bugzilla.gnome.org/show_bug.cgi?id=690118
Modify gsignal to automatically disconnect a GClosure that becomes
invalid (in the g_closure_invalidate() sense).
Previously, when g_signal_connect_object() was used with a GObject as
the user_data and that object was destroyed, the handler would no longer
be called but the signal handler was itself was not disconnected (ie:
the bookkeeping data was kept around).
The main effect of this patch is that these signal handlers will now
be automatically disconnected (and fully freed).
The documentation for g_signal_connect_object() has anticipated this
change for over 10 years and has advised the following workaround when
disconnecting signal handlers connected with g_signal_connect_object():
if (g_signal_handler_is_connected (instance, id))
g_signal_handler_disconnect (instance, id);
If your code follows this practice then it will continue to work.
If your code never disconnects the signal handler then it was wasting
memory before (and this commit fixes that).
If your code unconditionally disconnects the signal handler then you
will start to see (harmless) g_critical() warnings about this and you
should fix them.
https://bugzilla.gnome.org/show_bug.cgi?id=118536
If the optimization is used for only having one closure handling a
signal emission, then hooks will not be run, so it should be disabled
when an emission hook is added.
https://bugzilla.gnome.org/show_bug.cgi?id=671918
The trace of the signal emission of the was calculating the instance
type after the instance was unrefed. Fix this by keeping the instance type around.
When there is only one closure handling a signal emission and
it doesn't have a bunch of complicated features enabled we
can short circuit the va_args collection into GValues and call the
callback via the va_marshaller directly.
https://bugzilla.gnome.org/show_bug.cgi?id=661140
If the signal argumment types matches a built in standard
marshaller we use the va_marshaller for that, and also the
normal marshaller if NULL was specified (as its faster than
the generic one).
This lets you set a va_marshaller on your signal which will be
propagated to all closures for the signal. Also, automatically
uses the generica va_marshaller if you specify a NULL c_marshaller.
https://bugzilla.gnome.org/show_bug.cgi?id=661140
This means we're not abusing the notifiers for meta_marshallres,
and we're able to later cleanly add other fields to GClosure.
We still have to leave the ABI intact for the GClosure->meta_marshal
bit, as old G_CLOSURE_N_NOTIFIERS macro instances still accesses it.
However, we always set it to zero to keep those macros working.
https://bugzilla.gnome.org/show_bug.cgi?id=661140
Similar to G_PARAM_DEPRECATED. It will warn only for users of the
signals, so a signal can still be emited without warning, for
compatibility reasons.
Apparently, there is no way user flags could have been used before,
so that shouldn't break anyone.
https://bugzilla.gnome.org/show_bug.cgi?id=663581
To help cross compilation, don't use glib-genmarshal in our
build. This is easy now that we have g_cclosure_marshal_generic().
In gobject/, add gmarshal.[ch] to git (making the existing entry
points stubs).
In gio/, simply switch to using g_cclosure_marshal_generic().
https://bugzilla.gnome.org/show_bug.cgi?id=652168
In some cases, signal arguments have to be collected, even if there are i
no signal handlers connected (e.g. for GVariant parameters, where collection
consumes a floating variant).
Based on a patch by Christian Persch.
Bug #643624.
This adds static markers and systemtap tapsets for:
* type creation
* object lifetimes (creation, ref, unref, dispose, finalize)
* signal creation and emission
Signal emissions and finalization marker have a corresponding
*_end (or *-end in dtrace) version that is when the corresponding
operation is finished.
https://bugzilla.gnome.org/show_bug.cgi?id=606044
The reason we need to enforce this is that the GTypeValueTable
documentation explicitly states that memory is memset to 0 when the
value_init function is called.
https://bugzilla.gnome.org/show_bug.cgi?id=603590
Makes g_signal_emit_valist from 15% to 20% faster.
Results reported from profiling the pan newsreader which uses a variant
of simple and complex signal emissions (i.e no args or various args)
https://bugzilla.gnome.org/show_bug.cgi?id=603590
2009-03-13 Kristian Rietveld <kris@imendio.com>
* gsignal.c (signal_lookup_closure): when defaulting to the only
item in the array, check if this is indeed the default closure.
(patch by Tim Janik).
svn path=/trunk/; revision=7979
2008-07-21 Michael Natterer <mitch@imendio.com>
Reviewed by Tim Janik:
* gsignal.c (g_signal_chain_from_overridden_handler): allocate
the temp GValue array with GSLice.
(g_signal_emit_valist): dito. Remove optimization/obfuscation of
allocating up to 16 GValues on the stack and always use GSLice.
svn path=/trunk/; revision=7229
2008-07-04 Michael Natterer <mitch@imendio.com>
Bug 541208 – Functions to easily install and use signals without
class struct slot
* gobject.symbols
* gsignal.[ch] (g_signal_new_class_handler): the same as
_gtk_binding_signal_new(), to install signals with a callback
instead of a class struct slot as class closure.
The next two functions are C convenience and much easier to use
than the generic overriding and chaining APIs which are intended
primarily for language bindings:
(g_signal_override_class_handler): to override a signal with a
callback instead of a class struct slot.
(g_signal_chain_from_overridden_handler): to chain up from a
signal without class struct slot. The API is similar to
g_signal_emit().
svn path=/trunk/; revision=7157
2008-06-22 Michael Natterer <mitch@imendio.com>
* *.c: remove trailing whitespace from newly added gtk-doc
comments and reformatted some where they contained overly long or
ill-formatted lines.
svn path=/trunk/; revision=7090
2008-06-22 Michael Natterer <mitch@imendio.com>
* *.c: moved includes back to the top of the files (before gtk-doc
SECTION comments). Add "config.h" in all files and move system
included before glib includes. Remove trailing whitespace from
SECTION comments and did some reformatting where lines were overly
long, no documentation content was changed.
svn path=/trunk/; revision=7089
2007-08-14 Cody Russell <bratsche@gnome.org>
* gobject/gsignal.c: g_type_default_interface_ref() was not
ensuring working g_signal_list_ids. Added checks for
!G_TYPE_IS_INTERFACE (itype).
(#465625, by some guy who calls himself Yeti)
svn path=/trunk/; revision=5704
2005-12-30 Matthias Clasen <mclasen@redhat.com>
* gsignal.c: Remove the handler trash stack, which
is now unused.
(g_signal_init): Remove the restriction that HandlerMatch
must be the same size as GList, and obsolete comments
referring to mem chunks.
Tue Nov 1 16:24:20 2005 Tim Janik <timj@imendio.com>
* glib/gmem.[hc]: prepared deprecation of GMemChunk and GAllocator.
added g_slice_*() API to allocate and cache small bits of memory.
an actuall allocator implementation for g_slice_*() is still pending.
* glib/gthread.[hc]: changes from a patch by Matthias Clasen.
changed GRealThread list to use in-structure *next; fields instead
of GSList, in order for thread iteration to not depenend on g_slice_*()
indirectly.
_g_thread_mem_private_get():
_g_thread_mem_private_set(): added accessors for private memory,
needed because the ordinary GPrivate implementation relies on GArray
and GSList and therefore indirectly on working g_slice_*() allocations.
* glib/gthread.[hc]:
g_thread_foreach(): new public API function to loop over all existing threads.
* glib/gdataset.c:
* glib/gstring.c:
* glib/gcache.c:
* glib/garray.c:
* glib/gqueue.c:
* glib/gslist.c:
* glib/glist.c:
* glib/ghash.c:
* glib/gtree.c:
* glib/ghook.c:
* glib/gmain.c:
* glib/gnode.c:
removed GAllocator and free list usages and accompanying locks.
use g_slice_*() API to allocate and cache small bits of memory.
* glib/ghook.h: removed GMemChunk field from public API.
* glib/gslist.h:
* glib/glist.h: deprecate allocator API, provide _free1() for consistency.
* glib/gnode.h: deprecate allocator API.
* glib/gmain.c: reordered GPollRec fields so g_slice_free_chain() can
be used for poll rec lists.
* glib/grel.c: removed mem chunk usage, and allocated tuples via g_slice_*().
g_relation_destroy(): free all tuples from the all_tuples hash table,
this effectively maintains the life time track keeping of tuples.
g_relation_delete_tuple(): free tuples which are removed from the
all_tuples hash table. this fixes a temporary leak that was present
in the memchunk code until the destruction of the relation.
2005-09-08 Kjartan Maraas <kmaraas@gnome.org>
* gclosure.c: (g_closure_set_meta_marshal): Remove some unused
code.
* gsignal.c: (g_signal_emitv): Same here
* gtype.c: (g_type_register_fundamental): And here
* testgobject.c: Mark some functions static.
