Skip to content
Snippets Groups Projects
  1. Feb 09, 2019
  2. Jan 31, 2019
  3. Jan 30, 2019
  4. Jan 20, 2019
  5. Jan 17, 2019
  6. Jan 09, 2019
  7. Dec 16, 2018
  8. Dec 12, 2018
  9. Dec 05, 2018
  10. Nov 28, 2018
  11. Nov 27, 2018
    • Debarshi Ray's avatar
    • Debarshi Ray's avatar
      httpclient: Style fixes · 5cab7b7f
      Debarshi Ray authored
      5cab7b7f
    • Debarshi Ray's avatar
    • Debarshi Ray's avatar
      httpclient: Make the GCancellable handling thread-safe · e9114fe4
      Debarshi Ray authored
      A GCancellable can be cancelled from a different thread than the one
      where the GTask for the goa_http_client_check operation was created.
      Since the GCancellable::cancelled handler is invoked in the same thread
      as the g_cancellable_cancel call, unguarded access to the GError in
      CheckData is unsafe.
      
      Instead of introducing a GMutex, the GError can be set in the response
      callback which is guaranteed to be invoked in the same thread where the
      GTask was created. Ensuring that the GError is always accessed from the
      same thread makes it considerably easier to reason about its state.
      eg., it can be guaranteed that it won't be set if the status of the
      response isn't SOUP_STATUS_CANCELLED.
      e9114fe4
    • Debarshi Ray's avatar
      httpclient: Ensure that the GTask is always cleaned up · 0476f2ed
      Debarshi Ray authored
      The synchronous variant of goa_http_client_check runs a thread-specific
      GMainContext until the asynchronous variant invokes its callback. Once
      the callback is invoked, the GMainLoop is quit. This means that there
      won't be any further iterations of the loop and no new GSources will
      be dispatched.
      
      Therefore, when the synchronous HttpClient gets aborted by the
      GCancellable or due to an SSL error, then the following
      http_client_check_response_cb might not be invoked due to the lack of
      a running GMainLoop to drive the GMainContext; as a result, the GTask
      will get leaked.
      
      Solve this by tracking the GError and returning the GTask only when
      everything is complete.
      
      This was fixed in commit 3b35bd71, but
      broke in commit 73242fa2 when porting
      to GTask.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=764157
      0476f2ed
    • Debarshi Ray's avatar
      ewsclient: Simplify the clean up · 730e84ac
      Debarshi Ray authored
      Now that the deprecated SoupSessionAsync has been replaced with
      SoupSession [1], the response callbacks are invoked in the next
      iteration of the main loop after soup_session_abort has returned. This
      means that ews_client_autodiscover_response_cb is no longer called
      from a GCancellable::cancelled signal handler. Therefore, it's safe to
      directly disconnect from the GCancellable in the response callback
      without fearing for any deadlocks.
      
      This reverts commit 07f13b1d.
      
      [1] Commit 6c3e3c2d
      
      https://bugzilla.gnome.org/show_bug.cgi?id=764157
      730e84ac
    • Debarshi Ray's avatar
      httpclient: Simplify the clean up · 43ac806d
      Debarshi Ray authored
      Now that the deprecated SoupSessionAsync has been replaced with
      SoupSession [1], the response callbacks are invoked in the next
      iteration of the main loop after soup_session_abort has returned. This
      means that http_client_check_response_cb is no longer called from a
      GCancellable::cancelled signal handler. Therefore, it's safe to
      directly disconnect from the GCancellable in the response callback
      without fearing for any deadlocks.
      
      This reverts commit b2f94098.
      
      [1] Commit 6c3e3c2d
      
      https://bugzilla.gnome.org/show_bug.cgi?id=764157
      43ac806d
  12. Nov 26, 2018
  13. Nov 23, 2018
  14. Oct 28, 2018
  15. Oct 16, 2018
  16. Oct 03, 2018
  17. Oct 01, 2018
  18. Sep 05, 2018
  19. Sep 01, 2018
  20. Aug 20, 2018
  21. Aug 16, 2018