1. 06 May, 2021 4 commits
    • Philip Chimento's avatar
      Merge branch 'issue-326' into 'master' · 14a390c3
      Philip Chimento authored
      Working on Gio.ListStore.insert_sorted's compare_func
      See merge request !610
    • veena's avatar
    • Philip Chimento's avatar
      Merge branch 'april-maintenance' into 'master' · 037b23a6
      Philip Chimento authored
      April maintenance
      See merge request !616
    • Philip Chimento's avatar
      context: Collect nursery before heap dump · 247a4cda
      Philip Chimento authored
      Until now, mostly we didn't care about the nursery because only plain JS
      objects are created there; objects with finalizers, which comprise all of
      our custom objects in GJS, are automatically promoted to the tenured heap
      in SpiderMonkey's implementation of generational garbage collection.
      However, with the taking-out-the-garbage patches we will create a lot more
      Proxies (GObject wrappers) and plain objects (GObject expando objects)
      which can be allocated in the nursery. This can result in them being
      missing from heap dumps when we use the IgnoreNurseryObjects flag to
      The alternative is the CollectNurseryBeforeDump flag, which promotes any
      live objects in the nursery to the tenured heap. This way, we are
      certain to capture all of our wrappers and expando objects in the heap
      dump. The downside is that dumping the heap can now reduce performance.
      But it is something that should only be done for debugging, anyway.
      So here's this commit in advance of...
  2. 05 May, 2021 7 commits
  3. 04 May, 2021 17 commits
    • Philip Chimento's avatar
      arg-cache: Fix rebase collision · 7b1eb175
      Philip Chimento authored
      This was a more recent change than the branch that was just merged.
      Unreviewed, pushing to fix build.
    • Philip Chimento's avatar
      Merge branch '386-arg-cache-not-supported' into 'master' · cbd2c56f
      Philip Chimento authored
      arg-cache: Never throw when building the argument cache
      Closes #386
      See merge request GNOME/gjs!590
    • Philip Chimento's avatar
      Merge branch 'safer-toggle' into 'master' · 46f09493
      Philip Chimento authored
      Threads safer objects
      Closes #297, #404, and #406
      See merge request !613
    • Marco Trevisan's avatar
    • Marco Trevisan's avatar
      installed-tests: Mark thread-safe tests using a suite and run them in CI · 2deb7df6
      Marco Trevisan authored
      Add a new CI job running the tests with ThreadSanitizer, that greatly
      helps in checking what we could do wrong, especially now that we have
      code that we explicitly force to run in multiple threads.
    • Marco Trevisan's avatar
      repo: Always return on gjs_info_type_name to ensure it works without asserts · 46a31661
      Marco Trevisan authored
      Also required when compiling with -Db_sanitize=thread.
    • Marco Trevisan's avatar
      log: Optimize topics check avoiding repeated strings checks · c8328a83
      Marco Trevisan authored
      Avoid repeating the same string checks while debug logging.
      We can just save the enabled topics in a vector (if logging is enabled
      at all) and quickly check whether a topic is enabled.
    • Marco Trevisan's avatar
      log: Make logging thread safe · b17361cc
      Marco Trevisan authored
      ThreadSanitizer is complaining that we may set and use static values in
      a racy way, and that's true.
      So, handle this in an init/cleanup functions that we set and unset at
      context creation and cleanup.
    • Marco Trevisan's avatar
      context: Ensure we check atomically if we're destroying from other threads · e9a9c0f5
      Marco Trevisan authored
      At each toggle notification coming from another thread we check if
      we are destroying, however this value is set from the main thread (when
      the final gc starts), so we have to access to this atomically.
      Use std::atomic, and make ThreadSanitizer happy.
    • Marco Trevisan's avatar
      object: Rely on next ToggleQueue iteration to handle already queued toggle events · f52496c7
      Marco Trevisan authored
      When handling the toggle events from the main thread, we may have
      received a notification for a toggle event from multiple threads
      concurrently causing us to consider this an error.
      For example:
        Object 0x555555643b30 Toggle up, from main thread 1, queued down 1, up 1
        Object 0x555555643b30 Toggle down, from main thread 1, queued down 1, up 1
        Object 0x555555643b30 Toggle up, from main thread 0, queued down 0, up 0
        Object 0x555555643b30 Toggle up, from main thread 1, queued down 0, up 0
        Object 0x555555643b30 Toggle down, from main thread 0, queued down 0, up 0
        Object 0x555555643b30 Toggle down, from main thread 1, queued down 1, up 0
      Till the introduction of locked operations during toggle notifications
      we may not be sure how to handle this, but now we can be quite confident
      that we're working with the actual toggle queue state and so when an
      already-toggled event happens we can just be sure that it will be
      handled at next idle, and so we can stop considering it an error.
      To avoid having a queue of events that have no result, change the
      enqueue code to cancel a previously queued event that is the opposite of
      the one we're adding. We need to be able to add multiple events of the
      same type though (as could come from different threads), so adapt the
      cancellation code to this.
      As it's just something we can't control our level, but depends on other
      threads fired by applications. What we can do is only react properly,
      and now we do.
      Fixes: #297
    • Marco Trevisan's avatar
      toggle: Enforce thread-safety using a per-thread spin-lock · 02df4431
      Marco Trevisan authored
      While the ToggleQueue is expected to be thread-safe, unfortunately the
      way we use isn't always true.
      In fact, while we always perform operations locking the shared data, we
      may act on it depending on results that may have been changed by another
      thread. For example, we check if an object is queued or we cancel a
      queued object and we assume that this is true for the rest of the
      execution, but this may have been already changed meanwhile, thus we
      error later.
      This happens repeatedly with applications doing many fast threaded
      operations (an example can be triggered via GFileMonitor when the fs is
      particularly active as bug #297 shows).
      To avoid this, we need to ensure that all the access to the queue are
      locked till we're not done with it, but at the same time we must not to
      stop the owner thread to access multiple time to the queue while it owns
      the lock (as it may happen on recursion of we want group various
      To do this, control public access to the queue only via a structure that
      uses a spin-lock to block non-holder threads and that uses a refcounted
      system to handle the unlocking.
      So, any time we get the queue, we have a locked control of it, once the
      ToggleQueue::Locked structure is released, we unlock it only if no other
      instances in the current thread are using it.
      This serves us particularly well in the toggle notification callback
      where we had cases in which we were adding duplicate objects to the queue
      even if they were already there or vice versa we were not adding them
      because we the situation changed since the call to is_queued().
      Now instead, we can be sure that each thread will work on the current
      queue state and behave accordingly.
      Related-to: #297
    • Marco Trevisan's avatar
      toggle: Keep track of objects via ObjectInstance not GObject's · c2ba2ab0
      Marco Trevisan authored
      While the ToggleQueue serves us to track GObject's using their pointers
      is too fragile for us, because they can be also finalized from other
      threads and we may not be able to track when this happens, leaving them
      in the queue to be handled by the main thread, causing us to access to
      invalid memory.
      At the contrary, we totally control the life time of ObjectInstance's
      and we're sure that they always are created and destroyed in the main
      thread, so let's use them even inside the ToggleQueue.
      In this way:
       - We can keep using the same strategy to enqueue them
       - We don't have to rely on monitoring GObject's finalization to clear
         the queue (that again may not happen in main thread).
       - When an object wrapper is destroyed, we are sure that we've removed
         the gobject toggle reference, and so that we'll never get another
         toggle event queued again till another wrapper is created.
      Related to: #404
    • Marco Trevisan's avatar
      toggle: Rely on wrapper to cancel finalized objects in queue · 4e752437
      Marco Trevisan authored
      While GObject provides native tools to check if an object has been
      finalized using GWeakRef's, they have proved to be too fragile for us
      because they don't work well when used with toggle references
      notifications (not thread safe as glib#2384 demonstrates) and because
      may not be cleared on finalization (glib#2390).
      So, instead of adding further qdata to monitor a queued object
      finalization, let's just ensure that a wrapper cancels the toggle queue
      when its wrapped object get finalized.
      Since we don't touch the references of the object while adding it to the
      queue, we can also ignore remembering the current handled object, as no
      recursion can happen now.
      It may still happen (mostly due to the way we lock) that a finalized
      or unhandled object will be handled by the toggle handler, but this
      can't be really fixed for all the racy cases even at enqueue phase
      (like in the case a thread enqueues a toggle event just after we've
      disassociated the wrapper for such object).
      Fixes: #404
    • Marco Trevisan's avatar
    • Marco Trevisan's avatar
      arg-cache: Do not mark a function returning void* as skip-all · ab1a4ed0
      Marco Trevisan authored
      While it's true that a void function has no return value, this is not
      true in the case it's a void pointer.
      Not doing this, will cause a crash at ffi level because we're passing to
      it a null return value pointer, while it's expecting to fill it with
      the returned data.
      Fixes: #406
    • Marco Trevisan's avatar
      gjs-test-tools: Return GThread's when we don't join immediately · 8d77b058
      Marco Trevisan authored
      In this way we can join later in the tests or have more control on them.
    • Marco Trevisan's avatar
      gjs-test-tools: Ensure we use thread safe access to the saved object · cbd14c67
      Marco Trevisan authored
      Since we use this for testing actions from multiple threads, it's better
      to ensure that we have safe access to the variables.
      So use an atomic pointer to keep track of the saved object that allows
      us better control and make ThreadSanitizer happier.
  4. 30 Apr, 2021 2 commits
  5. 29 Apr, 2021 2 commits
    • Chun-wei Fan's avatar
      installed-tests: Fix building libgjstesttools · 76b092c1
      Chun-wei Fan authored
      ...on Visual Studio-style builds, since we need to explicitly mark the
      prototypes in the header for export, otherwise the build will fail as
      running g-ir-scanner will fail to find the export library for the DLL
      that was built.
    • Chun-wei Fan's avatar
      meson.build: Ignore warning C5030 on Visual Studio · f80a945e
      Chun-wei Fan authored
      We are now using C++17 attributes in place of the GLib macros as needed, so we
      can ignore warning C5030 that comes from attributes that are not recognized by
      the compiler, in particular the GCC-specific ones, since they simply not apply
      for Visual Studio builds.
  6. 27 Apr, 2021 1 commit
    • Marco Trevisan's avatar
      object: Block access to object only if it is finalized · 841a72bc
      Marco Trevisan authored
      For some time now we're warning whether a disposed object is used and
      this is sane, however the data it holds may be still valid and in
      general all the C code we access to is meant to be used after
      disposition. While such code has not to be called when the object is
      Since now we properly track objects finalization we can go back to allow
      most of the object actions (all but the signals connections, these
      involve having toggle notifications that are not a tool we can use
      at this point) with the actual object pointer.
      In case the object is finalized instead we behave exactly as before.
      Adapted tests and added ones for finalization case
  7. 25 Apr, 2021 1 commit
  8. 24 Apr, 2021 2 commits
  9. 23 Apr, 2021 2 commits
  10. 22 Apr, 2021 2 commits