Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
otb
otb
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 305
    • Issues 305
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 15
    • Merge Requests 15
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Main Repositories
  • otbotb
  • Issues
  • #2078

Closed
Open
Created Jul 17, 2020 by Luc Hermitte@lhermitteContributor

Release the Python Global Interpreter Lock (GIL) during execution

Description

It seems that Python application wrappers fail to release Python GIL.

Steps to reproduce

I observe the issue on s1tiling project, dependencies branch. In S1tiling, I use Dask to distribute the execution of OTB Applications. The OTB applications are actually started in Dask Workers (1 OTB app per worker) that are launched through Dask distributed.Client.get() method.

Dask complains that the workers cannot correctly communicate because the GIL isn't released:

distributed.core - INFO - Event loop was unresponsive in Worker for 9.67s.  This is often caused by long-running GIL-holding functions or moving large chunks of data. This can cause timeouts and instability.

It seems this issue has already been observed and, possibly, fixed on ITK side. See https://github.com/InsightSoftwareConsortium/ITK/pull/1065

I'm not sure where SWIG generation happens in order to insert the threads=1 parameters as done in ITK PR.

Configuration information

OTB 7.1, develop branch commit 2df70eaa, on Ubuntu with Dask 2.20.0, Python 3.6.9

Assignee
Assign to
8.0.0
Milestone
8.0.0
Assign milestone
Time tracking
None
Due date
None