Threading in python

[lee-deraud]

Can someone point me to anything in the documentation showing which functions do not execute in the main thread?

There are several mentions in the docs/examples of the restriction on updating the GUI from non-min threads, but most specific examples were deliberately contrived to demonstrate the post_to_main_thread() function. Only the callback designated by render_to_depth_image(() is explicitly called out as executing in its own thread, and I discovered (the hard way) the callbacks from file dialogs also seem to do so.

But I'd love to find some more elegant way to discover any others than by crashing the GUI.

[yashrajoria]

Hi @lee-deraud!

For Open3D GUI operations, you're dealing with thread-safety constraints similar to most GUI frameworks. Here's what you need to know:

Thread-Safe Approach

Instead of trying to find which functions are thread-safe, I'd recommend using Open3D's built-in threading model:

import open3d as o3d

def gui_update_callback():
    # Your GUI updates here
    # This runs safely in the main thread
    return True  # Return False to stop

# In your main thread
app = o3d.visualization.gui.Application.instance
app.post_to_main_thread(window, gui_update_callback)

General Pattern for Threaded Operations

from threading import Thread
import open3d as o3d

class MyVisualizer:
    def __init__(self):
        self.app = o3d.visualization.gui.Application.instance
        self.window = self.app.create_window("My Window", 1024, 768)
        
    def background_work(self):
        # Heavy computation in background thread
        result = self.process_point_cloud()
        
        # Post result back to main thread for GUI update
        self.app.post_to_main_thread(
            self.window,
            lambda: self.update_gui(result)
        )
    
    def update_gui(self, result):
        # All GUI operations here are safe
        pass

Key Guidelines

1. Computational work: Run in background threads
2. GUI updates: Always use post_to_main_thread()
3. Rendering operations: Must be in main thread
4. File I/O: Can be threaded, but post results to main thread for display

This pattern is more reliable than trying to determine which specific functions are thread-safe, as it can change between versions.

Hope this helps!

[lee-deraud]

Thanks, it's a much better answer than I got from stackoverflow anyway...

That said, I fully understand why and how I need to worry about thread safety. What I'm trying to figure out is WHEN I need to worry about it. And it's starting to sound like the answer is "all the time", since even functions that appear to be GUI-related or render-related can execute in other threads. I can control the threads I start myself, the ones started by open3d...not so much.

[yashrajoria]

Hi @lee-deraud,

That’s a very fair question — and you’re not missing anything in the docs.

In Open3D’s GUI layer, the only code that is reliably on the main thread is:

• Event callbacks you register on widgets (button clicks, sliders, menu items, etc.)
• The on_layout, on_draw, and similar window lifecycle callbacks
• Anything you explicitly dispatch via post_to_main_thread()

Everything else should be treated as potentially non-main-thread unless explicitly documented.

In particular:

• render_to_depth_image() is documented as threaded
• File dialog callbacks are indeed invoked from a worker thread
• Some async rendering / IO utilities may also not return on the UI thread

Unfortunately, there isn’t currently a central “these run off the main thread” list in the documentation. The safest mental model is:

If Open3D performs work asynchronously or via a callback that originates from IO, rendering, or background processing, assume it is NOT on the main thread.

If you want something deterministic, one practical trick during development is to assert thread identity:

import threading

def some_callback():
    assert threading.current_thread() is threading.main_thread()

That at least makes violations explicit instead of crashing the GUI unpredictably.

So yes, the pragmatic answer today is “worry about it unless you know you’re inside a UI event callback.”

If this is causing friction, it might be worth opening a documentation issue so the threading model is formally clarified. I suspect others would benefit from that.

[lee-deraud]

Not sure it's worth raising as a formal issue. (Not to mention that I have more important irons in that particular fire at the moment.)

I realize Open3D is more of a research tool than a commercial programming framework...it took way longer than it should have for me to get that. But I'm starting to wonder if I shouldn't just punt and work at the OpenGL level for my work. It's mostly just scanned STL post-processing, without any of the fancier machine-learning or scene reconstruction stuff. We shall see.