# Native GUI suggestion for Linux

**URL:** https://discourse.julialang.org/t/native-gui-suggestion-for-linux/34722
**Category:** General Usage
**Tags:** question
**Created:** [February 16, 2020, 1:56pm UTC](https://discourse.julialang.org/t/native-gui-suggestion-for-linux/34722 "2020-02-16T13:56:53Z")
**Posts on this page:** 1
**Showing post:** 8

<div class="post-metadata">

### Author: ![tobias.knopp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tobias.knopp/32/7551_2.png) [@tobias.knopp](https://discourse.julialang.org/u/tobias.knopp)
#### Post date: [February 16, 2020, 8:14pm UTC](https://discourse.julialang.org/t/native-gui-suggestion-for-linux/34722/8 "2020-02-16T20:14:33Z")

</div>

> [@Tamas\_Papp](#):
>
> 1. I want to do a blocking read from an audio source and do the processing; this is the bulk of the CPU usage and should probably live in its own thread (doing this fast is the main motivation for using Julia),
> 2. the above should deposit results in a shared container between threads,
> 3. another thread should do the display and control.

This is doable with Julia 1.3 which I outlined here: [Threading 1.3: Success Story](https://discourse.julialang.org/t/threading-1-3-success-story/27111)  
One issue at that time was that the `@spawn` macro may run on thread 1 but there has been some recent work ([[ANN] ThreadPools.jl - Improved thread management for background and nonuniform tasks](https://discourse.julialang.org/t/ann-threadpools-jl-improved-thread-management-for-background-and-nonuniform-tasks/33592)) that should make this feasible.

Regarding the concrete implementation: I think it is sufficient that you use one BG thread that does the processing. This BG thread can update the UI using `g_idle_add`. No need for an additional thread.

---

_[View the full topic](https://discourse.julialang.org/t/native-gui-suggestion-for-linux/34722)._