emilk / emilk/egui

frame.close() call with eframe on xorg not working if the main thread is still busy

Open
#3,573 2 comments 0 reactions 0 assignees View on GitHub
bug eframe
Dominant language
Rust
Stars
30.6k
Forks
2.1k
Avg merge
1d 9h
Merged PRs (30d)
72

Description

**Describe the bug**
calling frame.close in the app while the main thread is still busy with something else will not close the ui.

**To Reproduce**
```rust
use std::sync::Barrier;

use eframe::egui;

fn main() {
let options = eframe::NativeOptions {
..Default::default()
};
let _ = eframe::run_native("App", options, Box::new(|_cc| Box::::default()));

let bar = Barrier::new(2);
bar.wait();
}

struct MyApp {}

impl Default for MyApp {
fn default() -> Self {
Self {}
}
}

impl eframe::App for MyApp {
fn update(&mut self, _ctx: &egui::Context, frame: &mut eframe::Frame) {
frame.close()
}
}
```

In this example i create an app that should close itself right after creation. At the same time the main thread is busy waiting for some event or doing something different.

**Expected behavior**
the app window should close and the main thread should continue working on whatever its currently up to.

**Desktop (please complete the following information):**
- OS: Linux Ubuntu
- With X11 / xorg

**Additional context**
this works on windows

Contributor guide

Open the contributing guide

Research direction

Start by running the provided eframe::run_native example on Ubuntu with X11 and observe frame.close while the main thread waits on the Barrier. Trace the native window and event-loop handling for frame.close; done means the window closes while the main thread can continue, matching the reported Windows behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
desktop
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.