Commit Graph

153 Commits

Author SHA1 Message Date
Philip Withnall
38de3e9dc3 docs: Use ‘look up’ as a verb, rather than the noun ‘lookup’
Another niggle fixed.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-04-26 12:12:31 +01:00
Philip Withnall
d388a00028 docs: Fix typo in gsignal.c documentation comment
Spotted by Morten Welinder <mortenw@gnome.org>.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

https://bugzilla.gnome.org/show_bug.cgi?id=796186
2018-05-17 13:54:46 +01:00
Ryan Lortie
c64b6da33c gsignal: add assert on closure invalidate path
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
2017-11-15 12:51:12 +00:00
Stefan Sauer
2812219adb docs: add missing '*' chars at start of doc-comments 2017-11-12 16:36:16 +01:00
Sébastien Wilmet
6b948d9613 gobject/: LGPLv2+ -> LGPLv2.1+
All gobject/*.{c,h} files have been processed.

gmarshal.c and gmarshal.h don't have a license header.

https://bugzilla.gnome.org/show_bug.cgi?id=776504
2017-05-24 11:58:19 +02:00
Christian Hergert
18a33f72db introspection: use (nullable) or (optional) instead of (allow-none)
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.
2016-11-22 14:14:37 -08:00
Philip Withnall
9f4d5e8b91 gsignal: Mention handler ID type in signal connection macro docs
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.
2016-11-10 16:12:41 +00:00
Matthias Clasen
ef16cbee5b Don't set a va marshaller if a marshaller was set
Otherwise we get warnings when the caller later tries to set a
va marshaller with g_signal_set_va_marshaller.

https://bugzilla.gnome.org/show_bug.cgi?id=769076
2016-08-25 13:26:58 -04:00
Rico Tzschichholz
e3189527dc gio/gobject: Various introspection fixes 2016-02-03 18:13:49 +01:00
Philip Withnall
25a7c817d3 glib: Add missing (nullable) and (optional) annotations
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
2015-11-07 10:48:32 +01:00
Alexander Larsson
69002f726d signal: return TRUE from g_signal_has_handler_pending for custom class closure
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
2015-09-14 13:19:51 +02:00
Iain Lane
16721468e5 gsignal: Don't crash when operating on signals on the wrong object 2015-09-01 14:30:43 +01:00
Philip Withnall
ef1ba452b3 gsignal: Document memory management best practices for signal handlers
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
2015-08-19 12:56:38 +01:00
Matthias Clasen
916297be79 Add a global signal handler table
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
2015-05-27 14:41:19 -04:00
Philip Withnall
073a81d1da gsignal: Mark the return value of g_signal_emitv() as (inout) (optional)
https://bugzilla.gnome.org/show_bug.cgi?id=719966
2015-04-27 12:35:54 +01:00
Xavier Claessens
6a97275c45 docs: fix many documentation issues in gobject/ 2015-02-05 16:01:17 +01:00
Ryan Lortie
c476f7cd26 gsignal: add a clarification to the docs
As evidenced by a mistake that I made recently, this documentation could
use a little bit of clarification.
2014-11-28 16:22:16 -05:00
Benjamin Otte
36d8b941d4 signal: Keep only one list of emissions
There is no need to keep 2 lists.

This simplifies the code and gets rid of the only user inside glib of
G_HAVE_GROWING_STACK.

https://bugzilla.gnome.org/show_bug.cgi?id=736284
2014-10-12 00:27:06 +02:00
Ryan Lortie
dce88768dc all: remove use of 'register' keyword
We should have done this a decade ago...

https://bugzilla.gnome.org/show_bug.cgi?id=730293
2014-06-28 13:07:52 -04:00
Edward Hervey
c5c3c320a2 gvalue: New g_value_init_from_instance
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
2014-06-24 14:21:10 -04:00
Matthias Clasen
ad5b4bf92e Document g_signal_handlers_destroy 2014-05-31 10:54:02 -04:00
Sébastien Wilmet
430e6fd6ad doc: various improvements
- 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
2014-05-09 18:47:42 +02:00
Matthias Clasen
3232425785 Docs: replace <literal> by ` 2014-02-06 08:07:16 -05:00
Matthias Clasen
60b623d3fb GObject: Convert docs to markdown
In particular, convert lists to markdown syntax.
2014-02-01 10:22:45 -05:00
Matthias Clasen
a4c33c6f8b Docs: Don't use the code tag 2014-01-31 22:05:04 -05:00
Matthias Clasen
4d12e0d66f Docs: Don't use the emphasis tag
Most of the time, the text read just as well without the extra
boldness.
2014-01-31 20:34:33 -05:00
Daniel Mustieles
078dbda148 Updated FSF's address 2014-01-31 14:31:55 +01:00
Matthias Clasen
acfb76afe2 Docs: don't use <footnote>
It basically does not work in the HTML output.
2014-01-30 23:52:58 -05:00
Colin Walters
8f4dc7012e gsignal: Signal connection ids are always > 0 if successful
Note this explicitly so that people can rely on doing:

if (mystruct->sigid > 0)
  g_signal_disconnect (mystruct->object, mystruct->sigid);

https://bugzilla.gnome.org/show_bug.cgi?id=719809
2013-12-03 19:23:49 -05:00
Matthias Clasen
2baa50ee4f Remove g_trap_instance_signals as well
This is another crude conditional breakpoint mechanism and can
be done better with actual conditional breakpoints or with systemtap
tracepoints.

https://bugzilla.gnome.org/show_bug.cgi?id=719687
2013-12-03 06:00:47 -05:00
Martin Pitt
ed1e3816ad gobject-2.0: Annotate another GSignal function taking instances
As a followup to commit a72983a, annotate g_signal_handlers_destroy() as well.
2013-09-02 12:04:43 +02:00
Emmanuele Bassi
a72983a5db gobject-2.0: Annotate GSignal functions taking instances
Unbreak the GSignal API at least for GObject sub-classes.

https://bugzilla.gnome.org/show_bug.cgi?id=685387
2013-09-02 08:25:56 +02:00
Matthias Clasen
90da4ed628 Trivial typo fix 2013-07-28 22:06:57 -04:00
Ryan Lortie
3d1d49177b gsignal: remove some pointless locking
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
2013-05-23 21:50:54 -04:00
Dan Winship
4b94c0831e Use 'dumb quotes' rather than `really dumb quotes'
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
2013-05-21 11:23:22 -03:00
Ryan Lortie
f5d40bd813 gsignal: improve warning output
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
2013-02-22 00:54:50 +00:00
Alexander Larsson
aede774642 signals: Ensure we ref handler in emission fast path
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
2013-02-21 16:54:44 +01:00
Alexander Larsson
3e274423ba signals: No need to use atomics for Handler refcount
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
2013-02-21 16:54:44 +01:00
Ryan Lortie
d89fb7bf10 gsignal: fix closure invalidation code
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
2013-01-16 23:04:11 -05:00
Ryan Lortie
a36028f386 gsignal: really fix closure invalidation
Commit 66b0d95f0b missed this part of the
patch.
2012-10-13 12:16:32 -04:00
Ryan Lortie
c15769d304 [gsignal] fix up a crasher in previous commit
The previous commit introduced a new variable in the Handler struct but
didn't initialise it.  This was causing some tests to crash.

https://bugzilla.gnome.org/show_bug.cgi?id=118536
2012-10-08 11:21:58 -04:00
Matthias Clasen
d03d26feab [gsignal] disconnect invalidated closures
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
2012-10-08 11:21:48 -04:00
Colin Walters
56411bb678 gsignal: Properly handle NULL nodes 2012-06-22 10:32:25 -04:00
Mike Gorse
53b1afba0e Invalidate single_va_closure when adding an emission hook
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
2012-03-14 06:01:36 -04:00
Alexander Larsson
cb44e96dfa Fix crash in signal emission optimization
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.
2012-03-09 11:32:45 +01:00
Alexander Larsson
bbe4b57195 signal emission: Allocate instance_and_param with alloca
This Gives a 5% performance increase in e.g. the emit-handled test.
2012-03-09 09:57:03 +01:00
Emmanuele Bassi
75ca1cd158 gobject: Fix a compiler warning
Shuffle the parenthesis around.
2012-03-07 12:53:14 +00:00
Alexander Larsson
026340c5fc Fix unused variable warning 2012-03-06 11:35:17 +01:00
Matthias Clasen
afe30b2884 Fix a compiler warning 2012-03-05 07:54:47 -05:00
Alexander Larsson
2d6502f67b fastpath: Do allow NO_RECURSE fastpath for NOP emissions
This fixes a performance regression wrt the old NOP emission
handler.
2012-03-03 21:36:10 +01:00