364 Commits

Author SHA1 Message Date
Frediano Ziglio
e4ee3079c5 Do not wake up main loop if change is from same thread
This reduce the frequency the loop is waked up adding and removing
file descriptors or timeouts.
Considering that to support recursion events are removed from list and
added again this reduce iteration number a lot.

Signed-off-by: Frediano Ziglio <fziglio@redhat.com>

https://bugzilla.gnome.org/show_bug.cgi?id=761102
2016-07-16 21:08:51 -04:00
Philip Withnall
cfb692825a glib: Add more GLib main context SystemTap and DTrace probes
Expand the set of available probes, and add a few more output parameters
to some of the existing ones to make them more useful. I do not know if
this breaks any existing stability guarantees for GLib’s SystemTap
tapset, as it is effectively just adding some more local variables in
the user’s probe.

https://bugzilla.gnome.org/show_bug.cgi?id=759813
2016-06-15 16:15:12 -04:00
Aleksander Morgado
a340a5ef44 docs: improve g_main_context_push_thread_default() documentation
Explicitly suggest to use g_main_context_pop_thread_default() when there's no
user control on the life cycle of the thread being used.

https://bugzilla.gnome.org/show_bug.cgi?id=765173
2016-05-08 14:11:10 +02: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
Mikhail Zabaluev
75eaf5091c g_main_context_query(): Annotate @n_fds as (in) parameter
The default is picked up as (out), which is bogus.

https://bugzilla.gnome.org/show_bug.cgi?id=756099
2015-10-15 23:57:06 +03:00
Michael Catanzaro
a6ae52fa13 docs: Fix a typo finalised -> finalized
db8455f07d3d58b8d30d35371c0bbd3e342c8960 added use of both "finalised"
and "finalized". We generally use American spelling, so prefer that.
2015-08-21 16:46:33 -05:00
Philip Withnall
db8455f07d gmain: Document memory management best practices for GSources
It’s very common to see code where a timeout is scheduled using
g_timeout_add(), yet the owning object could be destroyed shortly
afterwards, before the timeout is fired, leading to use-after-free.

Try and prevent this happening with new code by documenting best
practices for memory management of user data for GSource callbacks.

https://bugzilla.gnome.org/show_bug.cgi?id=741779
2015-08-19 12:56:38 +01:00
Ryan Lortie
7c70377abf gmain: Save errno when handling unix signals
Our signal handler calls write() on a pipe or an eventfd in order to
deliver the notification.  It's unlikely, but this could fail, setting
errno.  We even check the case that it fails with EINTR.

If it does set errno, then it has potentially blown away the value or
errno that the preempted code cared about (ie: if the signal arrived
shortly after a system call but before errno was checked).

Wrap the handler with code to save errno.

https://bugzilla.gnome.org/show_bug.cgi?id=741791
2015-03-20 13:32:45 -04:00
Ryan Lortie
d9de830b65 Convert remaining uses of 'Rename to:'
This was replaced by (rename-to) in 2013 (see bug 676133).

They're also causing gtk-doc trouble, so let's get rid of them.
2015-03-12 16:55:22 -04:00
Philip Withnall
8df6e5fa3f gmain: Explicitly document the threading behaviour of g_timeout_add()
i.e. That calling g_timeout_add() from a thread other than the main one
probably doesn’t do what you want. Same for g_idle_add() and the
*_full() variants.

https://bugzilla.gnome.org/show_bug.cgi?id=741779
2015-03-03 18:40:33 +00:00
Ryan Lortie
5aba9ca837 gmain: fix poll record comparison
We intend to keep the list of poll records sorted by (integer) file
descriptor, but due to a typo we are actually keeping it sorted by
pointer address of the GPollFD.

Fix that.

https://bugzilla.gnome.org/show_bug.cgi?id=11059
2014-11-28 23:54:02 -05:00
Dan Winship
b3e3ed7386 gmain: don't pass the same fd to g_poll() multiple times
If a given fd is being polled by multiple sources, we used to pass it
multiple times to g_poll(), which is technically illegal (and not
supported by the select()-based fallback implementation of poll() in
gpoll.c), and also made it more likely that we'd exceed the maximum
number of pollfds.

Fix it to merge together "duplicate" GPollFDs. The easiest way to do
this involves re-sorting context->poll_records into fd order rather
than priority order. This means we now have to walk the entire pollrec
list for every g_main_context_query() and g_main_context_poll(),
rather than only walking the list up to the current max_priority.
However, this will only have a noticeable effect if you have tons of
GPollFDs, and we're already too slow in that case anyway because of
other O(n) operations that happen too often. So this shouldn't change
much (and the new poll API will eventually let us be cleverer).

Remove some win32-specific code which did the same thing (but was
O(n^2)).

https://bugzilla.gnome.org/show_bug.cgi?id=11059
2014-10-29 17:19:20 -04:00
Philip Withnall
1c6df7aaeb gmain: Unref child sources when finalising a GSource
If a GSource is created, *not* attached to a GMainContext, and then has
child sources added, dropping the last reference to the parent GSource
will leak its references to its child sources. Currently, child sources
are only unreffed when g_source_destroy() is called on the parent.

https://bugzilla.gnome.org/show_bug.cgi?id=737338
2014-09-25 13:59:25 +01:00
Philip Withnall
eaca86801e gmain: Fix some signed/unsigned integer comparisons
Just to shut gcc up.

https://bugzilla.gnome.org/show_bug.cgi?id=737338
2014-09-25 09:52:50 +01:00
Ryan Lortie
dceff8fc2c gmain: improve g_source_set_name thread safety
Step up thread safety on g_source_set_name() to the same standard as all
other GSource functions: after we are attached to a main context, this
function should be threadsafe.

https://bugzilla.gnome.org/show_bug.cgi?id=736683
2014-09-19 13:39:00 -04:00
Ryan Lortie
1cbdbef772 gsource: clarify restrictions on non-existant IDs
Document that one must not use the "by id" source APIs with non-existent
IDs.  The real justification behind this restriction is that the reuse
of source ids makes it unsafe to call these functions unless you're
absolutely sure that the source exists and it belongs to you.  If you
call one of these functions on a source that may already have been
removed then you run the risk of finding someone else's source (with
your reused id).

This also bails us out of a slightly tricky situation with respect to
the threadsafety of g_main_context_find_source_by_id().  The fact that
this function doesn't return a reference implies that its return value
cannot be safely accessed unless we already know for sure that a
reference is being held elsewhere (by example, by the main context
itself if we know that the source has not been removed).  The function
itself, however, performs an access to the value, which could result in
a crash.

If we mandate that it is only valid to call this function on
known-to-exist source IDs then we dodge this problem.

https://bugzilla.gnome.org/show_bug.cgi?id=736683
2014-09-19 13:39:00 -04:00
Руслан Ижбулатов
42ddcc6ff2 Silence some uncontroversial warnings
https://bugzilla.gnome.org/show_bug.cgi?id=711547
2014-08-02 12:38:38 +00:00
Ryan Lortie
393503ba5b gmain: simplify g_main_context_find_source_by_id()
Since we now keep a hashtable of sources, we can implement this function
without iteration.

https://bugzilla.gnome.org/show_bug.cgi?id=724839
2014-02-24 09:28:43 -05:00
Ryan Lortie
9e81709012 gmain: Simplify source id tracking
Simplify our tracking of issued source id integers and fix some bugs.

Previously the source's id was remove from the 'used' table from
source_remove_from_context() which was also called if the source
priority was changed (in which case it would never be added back to the
table).  The source id could be reissued in that case.

In the new approach, we just always keep a hash table of sources, by
source id.  This simplifies the logic and will also allow us to improve
performance of g_main_context_find_source_by_id() which is called in some
fairly common cases, such as g_source_remove().  These improvements will be in
the following commits.

https://bugzilla.gnome.org/show_bug.cgi?id=724839
2014-02-24 09:28:43 -05:00
Ryan Lortie
12d65f2509 GSource: mark some API as "implementation only"
Clarify that _add_poll() _remove_poll() _add_unix_fd(),
_modify_unix_fd(), _remove_unix_fd(), _query_unix_fd(),
_set_ready_time(), _add_child_source() and _remove_child_source() are only
intended to be used by the implementation of a particular GSource -- not its
consumers.

https://bugzilla.gnome.org/show_bug.cgi?id=724707
2014-02-22 10:25:06 -05:00
Ryan Lortie
6147d15ea2 gmain: repeat preconditions for emphasis
g_main_context_acquire() mentions that you must have called it before
you make any calls to _prepare(), _query(), _check() or _dispatch().

For emphasis, add a note on each of those functions pointing back to the
fact that you must have called _acquire() before using them.
2014-02-22 10:23:40 -05:00
Ryan Lortie
c0aa150cb0 g_main_context_wait: add a critical to detect use
Due to its unusual interface, I suspect that nobody is using
g_main_context_wait() but there is no way to know.

Add a critical notice that will be displayed if anyone calls the
function, asking them to file a bug with us.

We'll let this go out with the 2.40 release and see if we get a response
before we proceed with actually breaking the functionality.
2014-02-21 16:42:21 -05:00
Ryan Lortie
03a43c290e gmain: abort if monotonic time is unsupported
We now depend on CLOCK_MONOTONIC, but it's possible that people may
attempt to run GLib on systems where it isn't supported at runtime.

Check the return value of clock_gettime() and abort() if it fails in
order to save these people from wasting time on debugging a tricky
issue.

https://bugzilla.gnome.org/show_bug.cgi?id=670144
2014-02-21 16:42:21 -05:00
Ryan Lortie
0415930b49 gsource: document priority of child sources
Add a note to the documentation that child sources cannot have their priority
changed independently from their parent.  Add a g_return_if_fail() to the
public API in order to enforce this.

This was already a reality due to the check in
g_source_set_priority_unlocked(), but it was never explicitly documented.

https://bugzilla.gnome.org/show_bug.cgi?id=724706
2014-02-20 18:32:42 -05:00
Ryan Lortie
d614312546 gmain: rework g_get_monotonic_time() a bit
We now assume the existence of clock_gettime() and CLOCK_MONOTONIC as
specified by POSIX.1-2001.  This means that we always return truly
monotonic time, which will prevent problems in the case that the user
changes the time.

Mac OS doesn't have clock_gettime() but it does have
mach_absolute_time(), so we can use that there.

We keep our Windows case as well (although we should simplify it once XP
hits EOL later this year).

This patch removes the fallback to gettimeofday() in case of missing
clock_gettime().  We no longer have any way to test this codepath and
therefore it must go.

This patch also restructures the #ifdef a bit so that we repeat the
entire function definition inside of #ifdef instead of just the entire
body of one function.

https://bugzilla.gnome.org/show_bug.cgi?id=724687
2014-02-20 17:52:49 -05:00
William Jon McCann
20f4d1820b docs: use "Returns:" consistently
Instead of "Return value:".
2014-02-19 19:41:52 -05:00
Matthias Clasen
bc6ee788b4 docs: let go of &ast;
Since we are no longer using sgml mode, using /&ast; &ast;/ to
escape block comments inside examples does not work anymore.
Switch to using line comments with //
2014-02-14 21:33:36 -05:00
Simon McVittie
125913e9fe g_child_watch_source_new: POSIX pid must be positive
If we used a non-positive pid, we'd call waitpid(that_pid, ...)
which is exactly the situation this function can't deal with.

On Windows, GPid is a HANDLE (pointer), so I don't think the same thing
applies.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=723743
Reviewed-by: Ryan Lortie
2014-02-11 15:02:16 +00:00
Matthias Clasen
e7fd3de86d Eradicate links and xrefs
These are all replaced by markdown ref links.
2014-02-08 12:26:56 -05:00
Matthias Clasen
3232425785 Docs: replace <literal> by ` 2014-02-06 08:07:16 -05:00
Matthias Clasen
a35d8a4c77 Docs: use quotes instead of firstterm 2014-02-06 08:07:16 -05:00
Matthias Clasen
73c23d9143 Use markdown for images 2014-02-06 08:07:15 -05:00
Philip Withnall
5d71376763 gmain: Note that g_source_destroy() can be called multiple times
https://bugzilla.gnome.org/show_bug.cgi?id=723360
2014-02-03 07:55:44 +00:00
Matthias Clasen
d282bd3929 gmain: Convert docs to markdown
Specifically, convert sections to markdown syntax and
drop all the para tags.
2014-02-01 21:40:10 -05:00
Matthias Clasen
adf892e96a Annotate all examples with their language
The C ones, at least.
2014-02-01 15:11:49 -05:00
Matthias Clasen
42cf80780b Docs: Big entity cleanup
Strip lots of entity use from |[ ]| examples (which are now
implicit CDATA). Also remove many redundant uses of <!-- -->.
2014-02-01 12:00:30 -05:00
Matthias Clasen
85d612a968 gmain: Convert docs to markdown
In particular, convert lists to markdown syntax.
2014-02-01 10:22:44 -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
Ryan Lortie
8f6be404cb GMainContext: unref pending sources on destroy
It is possible (but unlikely) that there will be a non-empty list of
pending dispatches when we remove the last ref from a GMainContext.
Make sure we drop the refs on the sources appropriately.

Add a (now-working) testcase that demonstrates how to trigger the issue.

https://bugzilla.gnome.org/show_bug.cgi?id=139699
2014-01-19 17:41:18 -05:00
Ryan Lortie
1867fc210f unix signals: stop using atomics
They are not required here.  See the discussion in the bug report.

https://bugzilla.gnome.org/show_bug.cgi?id=711090
2014-01-02 20:38:40 -05:00
Ryan Lortie
76584e7ae3 Fix races in unix signal dispatch
Fix some races introduced in be2c7b83c4a9c9d3aa76b1499c27ab19e0f4e470
while keeping the property that multiple handlers for the same unix
signal all get dispatched.

Also fix the behaviour of the source checking for pending signals when
it's created.  No matter what we do here (clear the pending flag or not)
there is something that can go wrong.

If we clear the flag, we may prevent other sources from being
dispatched.  If we don't clear it, we may end up dispatching the same
source twice (if we manage to dispatch it from its own thread before the
GLib worker has a chance to run).

Instead, run the full dispatch procedure when a new source is added.  It
actually doesn't matter what thread this runs in since the lock is held.

https://bugzilla.gnome.org/show_bug.cgi?id=711090
2014-01-01 19:19:59 -05:00
Matthias Clasen
a9d93ca1df Add some mainloop instrumentation
Add trace points around adding, removing and dispatching of
sources.

https://bugzilla.gnome.org/show_bug.cgi?id=710741
2013-11-23 00:22:09 -05:00
Dan Winship
158dde0507 Replace #ifdef HAVE_UNISTD_H checks with #ifdef G_OS_UNIX
In Windows development environments that have it, <unistd.h> is mostly
just a wrapper around several other native headers (in particular,
<io.h>, which contains read(), close(), etc, and <process.h>, which
contains getpid()). But given that some Windows dev environments don't
have <unistd.h>, everything that uses those functions on Windows
already needed to include the correct Windows header as well, and so
there is never any point to including <unistd.h> on Windows.

Also, remove some <unistd.h> includes (and a few others) that were
unnecessary even on unix.

https://bugzilla.gnome.org/show_bug.cgi?id=710519
2013-11-20 09:25:39 -05:00
Dan Winship
51a917bc16 Remove alleged support for BeOS
Since the initial addition of BeOS support in 1999, there has only
been one update to it (in 2005, and it wasn't even very big). GLib is
known to not currently build on Haiku (or presumably actual BeOS)
without additional patching, and the fact that there isn't a single
G_OS_BEOS check in gio/ is suspicious.

Additionally, other than the GModule implementation, all of the
existing G_OS_BEOS checks are either (a) "G_OS_UNIX || G_OS_BEOS", or
(b) random minor POSIXy tweaks (include this header file rather than
that one, etc), suggesting that if we were going to support Haiku, it
would probably be simpler to treat it as a special kind of G_OS_UNIX
(as we do with Mac OS X) rather than as its own completely different
thing.

So, kill G_OS_BEOS.

https://bugzilla.gnome.org/show_bug.cgi?id=710519
2013-11-20 09:16:16 -05:00
Stef Walter
81d0ebe29c gmain: Fix use of uninitialized memory in sigaction structure
https://bugzilla.gnome.org/show_bug.cgi?id=711754
2013-11-11 07:40:16 +01:00
Ognyan Tonchev
64909ff740 gmain: make g_source_add_child_source() thread safe
g_source_add_child_source() releases the context lock before attaching
child_source to context. And this causes trouble if parent source is
blocked and g_main_dispatch() manages to lock the context mutex and call
unblock_source() before child_source gets attached to context.
To fix this we call g_source_attach_unlocked() before releasing the
context mutex.

https://bugzilla.gnome.org/show_bug.cgi?id=711064
2013-11-03 18:11:55 -05:00
Bastien Nocera
a919be3d39 gmain: Warn when g_source_remove() fails
Trying to remove a non-existent source should really be
a programming error, as the programmer could be trying to
use the wrong function to remove a callback, as seen when
GtkScrolledWindow tried to remove ID from another function
using g_source_remove().

See https://bugzilla.gnome.org/show_bug.cgi?id=710666#c12

https://bugzilla.gnome.org/show_bug.cgi?id=710724
2013-10-23 12:00:43 -04:00
Noah Massey
c4c3ee6087 gmain: mark newest id used when source id overflows
When the source id reaches G_MAXUINT (just prior to overflow), we
record the existing source ids to prevent reassigning them.  As we are
about to assign G_MAXUINT to the triggering source, that id should be
added as well.

https://bugzilla.gnome.org/show_bug.cgi?id=710002
2013-10-13 10:25:39 -04:00
Ryan Lortie
713614608d Fix a careless mistake in the last commit
Thanks Colin :)
2013-09-30 13:06:30 -04:00