The new "slowly add more task threads" code doesn't fully deal with
apps that queue lots and lots of tasks which then block on tasks from
their task threads. Fix this by bringing back the "task is blocking
other task" check and making sure that such tasks get bumped to the
front of the queue.
https://bugzilla.gnome.org/show_bug.cgi?id=687223
ntdef.h is a header that is normally only shipped with MinGW, not Visual
Studio, which broke the build in commit 975cb91. Fix this by including
winternl.h, which typedef's the NTSTATUS type in question on both Visual
Studio and MinGW/mingw-w64, as well as pre-2008 Visual Studio.
Clean up this inclusion part a little bit as well.
If we fail to PeekMessage or PostMessage we should make sure
that the output parameter bytes_read/written is set 0 instead
of being left uninitialized. This fixes an assertion in the io
channel call where the following invariant is checked:
(status == G_IO_STATUS_NORMAL) || (read_size == 0)
Ignore trailing whitespace when reading boolean values. Currently it is
very easy to manually edit a keyfile to be:
[section]
key=true_
Where '_' is a space character. g_key_file_get_boolean will read this value as
false and this is hard for a user to detect (it will be reported in GError
as an invalid value).
Trailing whitespace is ignored for numbers for the same reason. This was
fixed in 7a45dde4fe.
https://bugzilla.gnome.org/show_bug.cgi?id=664740
Now that we initialize the quark tables from a constructor,
reloading libglib is just as bad as reloading libgobject,
so add the linker option to the LDFLAGS for all our libraries.
https://bugzilla.gnome.org/show_bug.cgi?id=755609
Change it to a running example of a file viewer application with a file
class and various derived classes and related interfaces. Hopefully the
reader can relate to this a little better than to their maman.
https://bugzilla.gnome.org/show_bug.cgi?id=753935
We were using the time() library call to get the current time from the
system in order to compare it to the time returned by
g_date_time_new_now().
Of course, we took care to ensure that the time (in seconds) didn't
change in the middle of this process by checking the before and after
value of the system time.
Unfortunately, the system time as measured by time() was being taken
from a less-accurate clock source than the time used by GDateTime. As a
result, we could have GDateTime already into the next second while the
"seconds" value of the time returned by time() was still in the last
one, even when checked "after".
Avoid the problem by using the same ultimate source for time --
g_get_real_time().
This is based on a similar patch from Iain Lane, but it uses
g_get_real_time() instead of g_get_current_time().
https://bugzilla.gnome.org/show_bug.cgi?id=754994
This function provides an O(1) check to determine if a sequence is empty.
Compare this to the two following alternatives to perform the same check.
O(h): if (0 == g_sequence_get_length (seq))
O(2h): if (g_sequence_get_begin_iter(seq) == g_sequence_get_end_iter(seq))
Where `h' is the height of the tree.
https://bugzilla.gnome.org/show_bug.cgi?id=756316
It updates it to the version c5d07ce91a8ad51591154450442fa4376441fdfa
As a difference with upstream we need to ensure:
* Include "g-gnulib.h" so the methods get the gnulib namespace.
* xsize.h uses G_MAXSIZE instead of SIZE_MAX and the methods are
marked as static inline.
* Some defines are named different from the ones in glib i.e
HAVE_LONG_LONG_INT is HAVE_LONG_LONG
All the unit tests pass properly with and without --enable-included-printf.
It has also been tested on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=756382
Recent changes to file monitors removed the delay before events were
reported. Among other things, this caused the trash backend of gvfs to
notice trashed files sooner than before.
On noticing trashed files, the backend tries to read the info file to
discover (among other things) the original location of the file.
Unfortunately, g_local_file_trash() does a strange dance when trashing a
file. It does a loop of open(O_EXCL) in order to file an empty filename
in the trash to write an info file to, trashes the file, and only then
writes the contents of the info file. This means that at the time the
file is moved to the trash, the info file is an empty stub.
Change the order so that we write out the actual content of the info
file first. If the actual trash files then we will unlink the info file
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=749314
Add string serialisation functions for GNetworkAddress, GSocketAddress,
GUnixSocketAddress, GInetSocketAddress, GNetworkService and
GSocketConnectable. These are intended for use in debug output, not for
serialisation in network or disc protocols.
They are implemented as a new virtual method on GSocketConnectable:
g_socket_connectable_to_string().
GInetSocketAddress and GUnixSocketAddress now implement
GSocketConnectable directly to implement to_string(). Previously they
implemented it via their abstract parent class, GSocketAddress.
https://bugzilla.gnome.org/show_bug.cgi?id=737116
GDatagramBased is an interface abstracting datagram-based communications
in the style of the Berkeley sockets API. It may be contrasted to (for
example) GIOStream, which supports only streaming I/O.
GDatagramBased allows socket-like communications to be done through any
object, not just a concrete GSocket (which wraps socket()).
This adds the GDatagramBased interface, and implements it in GSocket.
https://bugzilla.gnome.org/show_bug.cgi?id=697907
The Visual Studio projects used a default setting for link-time code
generation, which is a part of the various linker optimizations that is
available, which is set as /LTCG for Visual Studio 2013 and earlier.
This changed in Visual Studio 2015 to become /LTCG:incremental, which would
cause GResources-generated code to be optimized out during linking, unless
they were referred to directly in the main line code (such as when the
GResource is manually registered), causing programs to crash as a result as
they can't find the needed code/data at run time.
Fix this by explicitly setting /LTCG for all release builds, for Visual
Studio 2010 and later.
https://bugzilla.gnome.org/show_bug.cgi?id=752837
Use /ltcg (link time code generation) for linking as well.
In fact, whole program optimization and /ltcg are the default for Release
builds, so we don't really have to set them explicitly in the projects, so
as a result, we can clean up the projects a little bit.
https://bugzilla.gnome.org/show_bug.cgi?id=752837
It seems that VS 2015 optimizes out the constructor on windows,
so it is better to use a DllMain to initialize the library
and keep using a normal constructor on the other platforms.
This research was done by Arnav Singh.
https://bugzilla.gnome.org/show_bug.cgi?id=752837
When G_OUTPUT_STREAM_CLOSE_TARGET is set,
g_output_stream_real_splice was not returning -1 in any error
cases, since the success flag was being overwritten.
https://bugzilla.gnome.org/show_bug.cgi?id=756255
By default g_log_default_handler always assumes that stdout
and stderr are file descriptors 1 and 2. On Win32 this isn't
always the case as the win32 API functions AttachConsole and
freopen can be used to dynamically attach GUI applications to
a console and the file descriptors of stderr and stdout will
become different than 1 and 2.
Fix it by using fputs with the FILE directly instead of
using the file descriptors.
https://bugzilla.gnome.org/show_bug.cgi?id=692085
The VerifyVersionInfo() Win32 API has been deprecated in Windows 10, and
there is no direct replacement for it, except by using a lower-level
RtlGetVersion() that we aquire from the Windows DDK or from ntdll.dll.
Switch g_win32_check_windows_version() to use RtlGetVersion(), and
compare its results with the input parameters.
https://bugzilla.gnome.org/show_bug.cgi?id=756179
The environment variable DISPLAY makes sense only for X11, it should
not be set in gio.
Beside, if the backend is not X11 but Wayland, forcing the value of
DISPLAY to the Wayland display will confuse the backend selection and
possibly crash the applications.
https://bugzilla.gnome.org/show_bug.cgi?id=754983
Commit a0cefc2217 introduced an unresolved
symbol, g_socket_send_message_with_timeout(), on win32. Windows
unfortunately isn’t clever enough to fill in the gaps and magic up the
implementation of that function from nowhere, so we had better do it
ourselves.
Factor the blocking behaviour out of g_socket_send_message() into a new
internal g_socket_send_message_with_timeout().
https://bugzilla.gnome.org/show_bug.cgi?id=756054
