Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • gstreamer gstreamer
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 675
    • Issues 675
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 355
    • Merge requests 355
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GStreamer
  • gstreamergstreamer
  • Issues
  • #270

Closed
Open
Created Jan 17, 2018 by Bugzilla Migration User@bugzilla-migration

"Race" when (de)activating pads

Submitted by Edward Hervey @bilboed

Link to original bug (#792595)

Description

Currently the following scenario can happen.

  • Thread 1 (from downstream elements) wants to reconfigure the scheduling mode of an upstream element (such as typefind)
  • Thread 2 (from the application or higher-level element) wants to deactivate the scheduling of that element.

The following "race" happens:

  • T2 calls gst_pad_set_active(pad, FALSE)
    ** T2 calls activate_mode_internal(pad, ..., FALSE)
    ** T2 pad was currently active, it eventually calls pre_activate(pad, GST_PAD_MODE_NONE), which sets in_activation to TRUE and GST_PAD_MODE(pad) to GST_PAD_MODE_NONE
    ** T2 calls the actual activation function
  • T1 calls gst_pad_activate_mode(pad, ..., TRUE)
    ** T2 calls activate_mode_internal(pad, ...., TRUE)
    ** T2 has GST_PAD_MODE_NONE, so carries on to call pre_activate
    ** T2 in pre_activate sees that in_activation is TRUE, so waits for the other thread to finish (and set in_activation to FALSE)
  • T2 finished calling the actual activation function and calls post_activate
    ** T2 set in_activation to FALSE and resumes succesfully, i.e. telling the caller that the pad is deactivated
  • T1 can resume activation and actually activates the pad

=> T2 assumes the pad is deactivated .... but it's not. (Note that the exact opposite could also happen).

Not entirely sure how this could be solved though.

Assignee
Assign to
Time tracking