mirror of
https://gitlab.gnome.org/GNOME/glib.git
synced 2025-07-15 06:36:48 +02:00
build
debian
docs
reference
Makefile.am
debugging.txt
macros.txt
gio
glib
gmodule
gobject
gthread
m4macros
po
tests
.gitignore
AUTHORS
COPYING
ChangeLog.pre-1-2
ChangeLog.pre-2-0
ChangeLog.pre-2-10
ChangeLog.pre-2-12
ChangeLog.pre-2-14
ChangeLog.pre-2-16
ChangeLog.pre-2-18
ChangeLog.pre-2-2
ChangeLog.pre-2-20
ChangeLog.pre-2-4
ChangeLog.pre-2-6
ChangeLog.pre-2-8
HACKING
INSTALL.in
MAINTAINERS
Makefile.am
Makefile.decl
NEWS
NEWS.pre-1-3
README.commits
README.in
README.win32
acglib.m4
acinclude.m4
autogen.sh
config.h.win32.in
configure.ac
gio-2.0-uninstalled.pc.in
gio-2.0.pc.in
gio-unix-2.0-uninstalled.pc.in
gio-unix-2.0.pc.in
gio-windows-2.0.pc.in
glib-2.0-uninstalled.pc.in
glib-2.0.pc.in
glib-gettextize.in
glib-zip.in
gmodule-2.0-uninstalled.pc.in
gmodule-2.0.pc.in
gmodule-export-2.0.pc.in
gmodule-no-export-2.0-uninstalled.pc.in
gmodule-no-export-2.0.pc.in
gobject-2.0-uninstalled.pc.in
gobject-2.0.pc.in
gthread-2.0-uninstalled.pc.in
gthread-2.0.pc.in
makefile.msc
mkinstalldirs
msvc_recommended_pragmas.h
sanity_check
win32-fixup.pl
8a3a4596e2
If sending a lot of data and/or the other peer is not reading it, then
socket buffers can overflow. This is communicated from the kernel by
returning EAGAIN. In GIO, it is modelled by g_output_stream_write()
and g_socket_send_message() returning G_IO_ERROR_WOULD_BLOCK.
It is also problematic that that we're using synchronous IO in the
shared GDBus IO thread. It means that one GDBusConnection can lock up
others.
It turns out that by porting from g_output_stream_write() to
g_output_stream_write_async() we fix the EAGAIN issue. For GSocket, we
still need to handle things manually (by creating a GSource) as
g_socket_send_message() is used.
We check the new behavior in Michael's producer/consumer test case (at
/gdbus/overflow in gdbus-peer.c) added in the last commit.
Also add a test case that sends and receives a 20 MiB message.
Also add a new `transport' G_DBUS_DEBUG option so it is easy to
inspect partial writes:
$ G_DBUS_DEBUG=transport ./gdbus-connection -p /gdbus/connection/large_message
[...]
========================================================================
GDBus-debug:Transport:
>>>> WROTE 128000 bytes of message with serial 4 and
size 20971669 from offset 0 on a GSocketOutputStream
========================================================================
GDBus-debug:Transport:
>>>> WROTE 128000 bytes of message with serial 4 and
size 20971669 from offset 128000 on a GSocketOutputStream
========================================================================
GDBus-debug:Transport:
>>>> WROTE 128000 bytes of message with serial 4 and
size 20971669 from offset 256000 on a GSocketOutputStream
[...]
========================================================================
GDBus-debug:Transport:
>>>> WROTE 43669 bytes of message with serial 4 and
size 20971669 from offset 20928000 on a GSocketOutputStream
[...]
========================================================================
GDBus-debug:Transport:
<<<< READ 16 bytes of message with serial 3 and
size 20971620 to offset 0 from a GSocketInputStream
========================================================================
GDBus-debug:Transport:
<<<< READ 15984 bytes of message with serial 3 and
size 20971620 to offset 16 from a GSocketInputStream
========================================================================
GDBus-debug:Transport:
<<<< READ 16000 bytes of message with serial 3 and
size 20971620 to offset 16000 from a GSocketInputStream
[...]
========================================================================
GDBus-debug:Transport:
<<<< READ 144000 bytes of message with serial 3 and
size 20971620 to offset 20720000 from a GSocketInputStream
========================================================================
GDBus-debug:Transport:
<<<< READ 107620 bytes of message with serial 3 and
size 20971620 to offset 20864000 from a GSocketInputStream
OK
https://bugzilla.gnome.org/show_bug.cgi?id=626748
Signed-off-by: David Zeuthen <davidz@redhat.com>