We can't safely close the output part of the I/O stream until any
pending write or flush has been completed. In the worst case, this could
lead to an assertion failure in the worker (when the close wins the
race) or not closing the stream at all (when the write wins the race).
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=651268
Bug-NB: NB#271520
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Signed-off-by: David Zeuthen <davidz@redhat.com>
num_writes_pending was a counter, but it only took values 0 or 1, so make
it a boolean: it would never make sense to be trying to write out two
messages at the same time (they'd get interleaved).
Similarly, we can never be writing and flushing at the same time (that'd
mean we were flushing halfway through a message, which would be pointless)
so combine it with flush_pending too, calling the result output_pending.
Also assert that it takes the expected value whenever we change it,
and document the locking discipline used for it, including a subtle
case in write_message_in_idle_cb where it's not obvious at first glance
why we don't need the lock.
(Having the combined boolean at the top of the block of write-related
struct members improves struct packing on 64-bit platforms, by packing
read_num_ancillary_messages and output_pending into one word.)
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=651268
Bug-NB: NB#271520
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Signed-off-by: David Zeuthen <davidz@redhat.com>
* Do not ignore the system default
* Do not exclude the last used being set from the default list
This fixes the default applications dialog in control-center.
https://bugzilla.gnome.org/show_bug.cgi?id=658188
Define USE_SYSTEM_PCRE for all configurations which uses the PCRE that was
already built and "installed" beforehand (i.e. the *_ExtPCRE
configurations) so that the compilation will not pick up the GLib-bundled
pcre.h when one wants to use the PCRE "installation" on his/her system.
This time I realized that I needed to set autocrlf=false on my Windows side
... ugh...
This is one of those files that must have CRLF line endings to work
correctly :|
-Reinstate the temporarily removed glib.sln file for VS10--make its EOL
in the DOS/Windows format so that it will not end up with "Unrecognized
Visual Studio Version" in Windows.
-Updated GLib projects to set the GLib DLL/LIB files to be output to
<Debug or Release>\<Win32 or x64>\bin for all configurations
-Updated property sheets to copy the GLib DLL/LIB for all configurations
-Update VS9 property sheet to seperate Intermediate directories for all
projects as well to reduce warnings/errors of being unable to write the
PDB and related files as they are in use
-Seperate intermediate directories for each project to avoid intermittent
MSBuild errors that a build log cannot be written while in use, and
update the property sheet as necessary.
-Minor cleanups of uneeded tags in the projects/properties
These tools require the use of GModule headers also, so update the include
directories so that the correct gmodule.h will be included instead of the
system-installed version.
Use the opt-out mechanism introduced in gtk-doc 1.16 to work
around problems with the _utf8 renaming games that the win32
port is playing in our headers.
https://bugzilla.gnome.org/show_bug.cgi?id=638449
