1. 14 Mar, 2019 1 commit
  2. 13 Mar, 2019 2 commits
  3. 08 Mar, 2019 4 commits
  4. 07 Mar, 2019 3 commits
  5. 06 Mar, 2019 2 commits
  6. 05 Mar, 2019 2 commits
  7. 04 Mar, 2019 4 commits
  8. 27 Feb, 2019 3 commits
  9. 25 Feb, 2019 3 commits
  10. 22 Feb, 2019 3 commits
  11. 21 Feb, 2019 3 commits
    • Philip Withnall's avatar
      tests: Unmark socket-service test as flaky · 07414e17
      Philip Withnall authored
      This essentially reverts commit
      The preceding two commits have fixed the test so it’s no longer flaky.
      The following command gives 5000 passes in a row for me:
      meson test -C /opt/gnome/build/glib/ socket-service --repeat 5000
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      Fixes: #1679
    • Philip Withnall's avatar
      tests: Fix unlikely race in socket-service test · f25c3f27
      Philip Withnall authored
      It’s occasionally possible for the cancellation of the service to happen
      before connection_cb() gets scheduled in the other thread. The
      locking/unlocking order of mutex_712570 requires:
       • test_threaded_712570(): lock mutex
       • test_threaded_712570(): start wait loop
       • connection_cb(): lock mutex
       • test_threaded_socket_service_finalize(): unlock mutex
       • test_threaded_712570(): end wait loop
       • test_threaded_712570(): unlock mutex
      Fix that by quitting the main loop once connection_cb() has been called
      (i.e. once the server thread has received the incoming connection
      request), rather than just after the client thread (main thread) has
      sent a connection request.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      Helps: #1679
    • Philip Withnall's avatar
      tests: Fix flaky socket-service test caused by GTask scheduling · 2aea9c84
      Philip Withnall authored
      On about 1 in 3 test runs, the socket-service would fail with the
      ref_count assertion in connection_cb() failing (the ref_count would be 3
      rather than the expected 2).
      This was happening because the GTask from
      g_socket_listener_accept_socket_async() now always takes at least one
      main context iteration to return a result (whereas before
      6f3d57d2 it might have taken zero), but
      the ref_count can drop below 3 before the process of returning a result
      starts. During the process of returning a result, the ref_count
      temporarily increases again, which is what was breaking the test.
      Fix this by waiting for one more main context iteration. This is a bit
      of a hack, but the real fix would be to expose the outstanding_accept
      boolean from GSocketService as public API (which the test can
      interrogate), and that seems too much like exposing internal state.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      Helps: #1679
  12. 20 Feb, 2019 3 commits
    • Nirbheek Chauhan's avatar
      meson: Add gobjectenumtypes.h to gioenumtypes_dep · 2d6c4b28
      Nirbheek Chauhan authored
      Almost everything that needs gioenumtypes.h also needs
      gobjectenumtypes.h. Fixes:
      ccache cc @gio/win32/gio@win32@@giowin32@sta/gwin32filemonitor.c.obj.rsp
      In file included from ../gio/win32/gwin32filemonitor.h:25:0,
                       from ../gio/win32/gwin32filemonitor.c:26:
      ../glib/glib-object.h:37:10: fatal error: gobject/gobjectenumtypes.h: No such file or directory
       #include <gobject/gobjectenumtypes.h>
    • Nirbheek Chauhan's avatar
      gio: Also support modules built with MSVC · 8e3fc7df
      Nirbheek Chauhan authored
      GIO modules built with MSVC do not begin with 'lib', but they can
      begin with 'gio'. Without this, you can only load GIO modules built
      with MSVC that are `name.dll`, not `gioname.dll`.
    • Felix Potthast's avatar
      glib-compile-resources: Fixes #1675 · 45655b82
      Felix Potthast authored
  13. 18 Feb, 2019 1 commit
    • Emmanuele Bassi's avatar
      Initialize a variable · f011be9c
      Emmanuele Bassi authored
      Compilers get confused when variables are initialized by a function by
      taking them as reference in an out argument; this, coupled with the fact
      that C does not initialize variables by default, most commonly results
      in a "maybe uninitialized" compiler warning.
  14. 14 Feb, 2019 4 commits
  15. 13 Feb, 2019 2 commits
    • LRN's avatar
      socket test: Use loopback for connecting, not · c00724d5
      LRN authored
      getsockname() returns the address that the socket was bound to.
      If it was bound to INADDR_ANY, getsockname() will stubbornly return INADDR_ANY
      (and someport - that one is valid).
      Subsequent connection attempts to INADDR_ANY:someport will fail with winsock.
      Actually, it doesn't make even sense to connect to INADDR_ANY at all
      (where is the socket connecting to? To a random interface of the host?),
      so this is just a straight-up change, without platform-specific ifdefing.
      Use loopback instead of INADDR_ANY. To ensure that binding and creation
      of INADDR_ANY is still tested, use two addresses: bind to INADDR_ANY,
      but connect to loopback, with the port number that we got from the bound
    • Jordan Petridis's avatar
      gpollableoutputstream: Fix the description of the interface · 3e77699c
      Jordan Petridis authored
      Looks like this was a copy-paste typo from the Input interface.