2019-08-18 18:49:20 +03:00
|
|
|
#[cfg(windows)]
|
|
|
|
use crate::os::windows::event::EventHandle;
|
2019-08-18 19:27:41 +03:00
|
|
|
#[cfg(target_os = "macos")]
|
|
|
|
use core_foundation::runloop::*;
|
2019-08-18 18:49:20 +03:00
|
|
|
use failure::Fallible;
|
|
|
|
use promise::{BasicExecutor, SpawnFunc};
|
|
|
|
use std::collections::VecDeque;
|
|
|
|
use std::sync::{Arc, Mutex};
|
2019-08-18 19:30:58 +03:00
|
|
|
#[cfg(all(unix, not(target_os = "macos")))]
|
|
|
|
use {
|
|
|
|
filedescriptor::{FileDescriptor, Pipe},
|
|
|
|
mio::unix::EventedFd,
|
|
|
|
mio::{Evented, Poll, PollOpt, Ready, Token},
|
|
|
|
std::os::unix::io::AsRawFd,
|
|
|
|
};
|
2019-08-18 18:49:20 +03:00
|
|
|
|
|
|
|
lazy_static::lazy_static! {
|
|
|
|
pub(crate) static ref SPAWN_QUEUE: Arc<SpawnQueue> = Arc::new(SpawnQueue::new().expect("failed to create SpawnQueue"));
|
|
|
|
}
|
|
|
|
|
|
|
|
pub(crate) struct SpawnQueue {
|
|
|
|
spawned_funcs: Mutex<VecDeque<SpawnFunc>>,
|
2019-08-18 18:57:07 +03:00
|
|
|
|
|
|
|
#[cfg(windows)]
|
2019-08-18 18:49:20 +03:00
|
|
|
pub event_handle: EventHandle,
|
|
|
|
|
2019-08-18 18:57:07 +03:00
|
|
|
#[cfg(all(unix, not(target_os = "macos")))]
|
2019-08-18 18:49:20 +03:00
|
|
|
write: Mutex<FileDescriptor>,
|
2019-08-18 18:57:07 +03:00
|
|
|
#[cfg(all(unix, not(target_os = "macos")))]
|
2019-08-18 18:49:20 +03:00
|
|
|
read: Mutex<FileDescriptor>,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl SpawnQueue {
|
|
|
|
pub fn new() -> Fallible<Self> {
|
|
|
|
Self::new_impl()
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn spawn(&self, f: SpawnFunc) {
|
|
|
|
self.spawn_impl(f)
|
|
|
|
}
|
|
|
|
|
fix a starvation issue on linux/x11 systems
The `SpawnQueue::run_impl` would loop until it had exhausted
all queued items. This prevents returning to the main loop
and resulted in the UI hanging while eg: `yes` was running,
and could also block accepting keyboard input, which is
pretty bad.
In addition, the queue implementation could fill up a pipe
and block the write side while it held a lock, which in
turn would prevent the read side from making room for the
write to succeed!
This commit changes the behavior on linux to change the wakeup
behavior of the queue from having a 1:1 relationship between
enqueue:wakeup to n:m where n and m are both >= 1. This is
sufficient to wake a sleeping gui thread. The gui thread
can then pop and process a single item at a time, interleaved
with dispatching the gui events.
The result is a bit more responsive, however, there is no
backpressure from the gui to the read side, so if the read
side is eating 2MB/s of data and the GUI side is processing
less than this, then an interrupt signal may still take a
few seconds to take effect.
I have mixed feelings about adding backpressure, because
I'm not sure that it is worth actually rendering all of
the parsed output text when there is a lot of it.
I need to follow up and verify these changes on macOS
and Windows too.
Refs: https://github.com/wez/wezterm/issues/65
2019-11-22 03:43:08 +03:00
|
|
|
pub fn run(&self) -> bool {
|
2019-08-18 18:49:20 +03:00
|
|
|
self.run_impl()
|
|
|
|
}
|
2019-08-18 18:57:07 +03:00
|
|
|
|
|
|
|
// This needs to be a separate function from the loop in `run`
|
|
|
|
// in order for the lock to be released before we call the
|
|
|
|
// returned function
|
|
|
|
fn pop_func(&self) -> Option<SpawnFunc> {
|
|
|
|
self.spawned_funcs.lock().unwrap().pop_front()
|
|
|
|
}
|
2019-08-18 18:49:20 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
#[cfg(windows)]
|
|
|
|
impl SpawnQueue {
|
|
|
|
fn new_impl() -> Fallible<Self> {
|
|
|
|
let spawned_funcs = Mutex::new(VecDeque::new());
|
|
|
|
let event_handle = EventHandle::new_manual_reset().expect("EventHandle creation failed");
|
|
|
|
Ok(Self {
|
|
|
|
spawned_funcs,
|
|
|
|
event_handle,
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
fn spawn_impl(&self, f: SpawnFunc) {
|
|
|
|
self.spawned_funcs.lock().unwrap().push_back(f);
|
|
|
|
self.event_handle.set_event();
|
|
|
|
}
|
|
|
|
|
fix a starvation issue on linux/x11 systems
The `SpawnQueue::run_impl` would loop until it had exhausted
all queued items. This prevents returning to the main loop
and resulted in the UI hanging while eg: `yes` was running,
and could also block accepting keyboard input, which is
pretty bad.
In addition, the queue implementation could fill up a pipe
and block the write side while it held a lock, which in
turn would prevent the read side from making room for the
write to succeed!
This commit changes the behavior on linux to change the wakeup
behavior of the queue from having a 1:1 relationship between
enqueue:wakeup to n:m where n and m are both >= 1. This is
sufficient to wake a sleeping gui thread. The gui thread
can then pop and process a single item at a time, interleaved
with dispatching the gui events.
The result is a bit more responsive, however, there is no
backpressure from the gui to the read side, so if the read
side is eating 2MB/s of data and the GUI side is processing
less than this, then an interrupt signal may still take a
few seconds to take effect.
I have mixed feelings about adding backpressure, because
I'm not sure that it is worth actually rendering all of
the parsed output text when there is a lot of it.
I need to follow up and verify these changes on macOS
and Windows too.
Refs: https://github.com/wez/wezterm/issues/65
2019-11-22 03:43:08 +03:00
|
|
|
fn run_impl(&self) -> bool {
|
2019-08-18 18:49:20 +03:00
|
|
|
self.event_handle.reset_event();
|
fix a starvation issue on linux/x11 systems
The `SpawnQueue::run_impl` would loop until it had exhausted
all queued items. This prevents returning to the main loop
and resulted in the UI hanging while eg: `yes` was running,
and could also block accepting keyboard input, which is
pretty bad.
In addition, the queue implementation could fill up a pipe
and block the write side while it held a lock, which in
turn would prevent the read side from making room for the
write to succeed!
This commit changes the behavior on linux to change the wakeup
behavior of the queue from having a 1:1 relationship between
enqueue:wakeup to n:m where n and m are both >= 1. This is
sufficient to wake a sleeping gui thread. The gui thread
can then pop and process a single item at a time, interleaved
with dispatching the gui events.
The result is a bit more responsive, however, there is no
backpressure from the gui to the read side, so if the read
side is eating 2MB/s of data and the GUI side is processing
less than this, then an interrupt signal may still take a
few seconds to take effect.
I have mixed feelings about adding backpressure, because
I'm not sure that it is worth actually rendering all of
the parsed output text when there is a lot of it.
I need to follow up and verify these changes on macOS
and Windows too.
Refs: https://github.com/wez/wezterm/issues/65
2019-11-22 03:43:08 +03:00
|
|
|
let mut did_any = false;
|
2019-08-18 18:57:07 +03:00
|
|
|
while let Some(func) = self.pop_func() {
|
|
|
|
func();
|
fix a starvation issue on linux/x11 systems
The `SpawnQueue::run_impl` would loop until it had exhausted
all queued items. This prevents returning to the main loop
and resulted in the UI hanging while eg: `yes` was running,
and could also block accepting keyboard input, which is
pretty bad.
In addition, the queue implementation could fill up a pipe
and block the write side while it held a lock, which in
turn would prevent the read side from making room for the
write to succeed!
This commit changes the behavior on linux to change the wakeup
behavior of the queue from having a 1:1 relationship between
enqueue:wakeup to n:m where n and m are both >= 1. This is
sufficient to wake a sleeping gui thread. The gui thread
can then pop and process a single item at a time, interleaved
with dispatching the gui events.
The result is a bit more responsive, however, there is no
backpressure from the gui to the read side, so if the read
side is eating 2MB/s of data and the GUI side is processing
less than this, then an interrupt signal may still take a
few seconds to take effect.
I have mixed feelings about adding backpressure, because
I'm not sure that it is worth actually rendering all of
the parsed output text when there is a lot of it.
I need to follow up and verify these changes on macOS
and Windows too.
Refs: https://github.com/wez/wezterm/issues/65
2019-11-22 03:43:08 +03:00
|
|
|
did_any = true;
|
2019-08-18 18:49:20 +03:00
|
|
|
}
|
fix a starvation issue on linux/x11 systems
The `SpawnQueue::run_impl` would loop until it had exhausted
all queued items. This prevents returning to the main loop
and resulted in the UI hanging while eg: `yes` was running,
and could also block accepting keyboard input, which is
pretty bad.
In addition, the queue implementation could fill up a pipe
and block the write side while it held a lock, which in
turn would prevent the read side from making room for the
write to succeed!
This commit changes the behavior on linux to change the wakeup
behavior of the queue from having a 1:1 relationship between
enqueue:wakeup to n:m where n and m are both >= 1. This is
sufficient to wake a sleeping gui thread. The gui thread
can then pop and process a single item at a time, interleaved
with dispatching the gui events.
The result is a bit more responsive, however, there is no
backpressure from the gui to the read side, so if the read
side is eating 2MB/s of data and the GUI side is processing
less than this, then an interrupt signal may still take a
few seconds to take effect.
I have mixed feelings about adding backpressure, because
I'm not sure that it is worth actually rendering all of
the parsed output text when there is a lot of it.
I need to follow up and verify these changes on macOS
and Windows too.
Refs: https://github.com/wez/wezterm/issues/65
2019-11-22 03:43:08 +03:00
|
|
|
did_any
|
2019-08-18 18:49:20 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#[cfg(all(unix, not(target_os = "macos")))]
|
|
|
|
impl SpawnQueue {
|
|
|
|
fn new_impl() -> Fallible<Self> {
|
fix a starvation issue on linux/x11 systems
The `SpawnQueue::run_impl` would loop until it had exhausted
all queued items. This prevents returning to the main loop
and resulted in the UI hanging while eg: `yes` was running,
and could also block accepting keyboard input, which is
pretty bad.
In addition, the queue implementation could fill up a pipe
and block the write side while it held a lock, which in
turn would prevent the read side from making room for the
write to succeed!
This commit changes the behavior on linux to change the wakeup
behavior of the queue from having a 1:1 relationship between
enqueue:wakeup to n:m where n and m are both >= 1. This is
sufficient to wake a sleeping gui thread. The gui thread
can then pop and process a single item at a time, interleaved
with dispatching the gui events.
The result is a bit more responsive, however, there is no
backpressure from the gui to the read side, so if the read
side is eating 2MB/s of data and the GUI side is processing
less than this, then an interrupt signal may still take a
few seconds to take effect.
I have mixed feelings about adding backpressure, because
I'm not sure that it is worth actually rendering all of
the parsed output text when there is a lot of it.
I need to follow up and verify these changes on macOS
and Windows too.
Refs: https://github.com/wez/wezterm/issues/65
2019-11-22 03:43:08 +03:00
|
|
|
// On linux we have a slightly sloppy wakeup mechanism;
|
|
|
|
// we have a non-blocking pipe that we can use to get
|
|
|
|
// woken up after some number of enqueues. We don't
|
|
|
|
// guarantee a 1:1 enqueue to wakeup with this mechanism
|
|
|
|
// but in practical terms it does guarantee a wakeup
|
|
|
|
// if the main thread is asleep and we enqueue some
|
|
|
|
// number of items.
|
|
|
|
// We can't affort to use a blocking pipe for the wakeup
|
|
|
|
// because the write needs to hold a mutex and that
|
|
|
|
// can block reads as well as other writers.
|
2019-08-18 18:49:20 +03:00
|
|
|
let pipe = Pipe::new()?;
|
fix a starvation issue on linux/x11 systems
The `SpawnQueue::run_impl` would loop until it had exhausted
all queued items. This prevents returning to the main loop
and resulted in the UI hanging while eg: `yes` was running,
and could also block accepting keyboard input, which is
pretty bad.
In addition, the queue implementation could fill up a pipe
and block the write side while it held a lock, which in
turn would prevent the read side from making room for the
write to succeed!
This commit changes the behavior on linux to change the wakeup
behavior of the queue from having a 1:1 relationship between
enqueue:wakeup to n:m where n and m are both >= 1. This is
sufficient to wake a sleeping gui thread. The gui thread
can then pop and process a single item at a time, interleaved
with dispatching the gui events.
The result is a bit more responsive, however, there is no
backpressure from the gui to the read side, so if the read
side is eating 2MB/s of data and the GUI side is processing
less than this, then an interrupt signal may still take a
few seconds to take effect.
I have mixed feelings about adding backpressure, because
I'm not sure that it is worth actually rendering all of
the parsed output text when there is a lot of it.
I need to follow up and verify these changes on macOS
and Windows too.
Refs: https://github.com/wez/wezterm/issues/65
2019-11-22 03:43:08 +03:00
|
|
|
let on = 1;
|
|
|
|
unsafe {
|
|
|
|
libc::ioctl(pipe.write.as_raw_fd(), libc::FIONBIO, &on);
|
|
|
|
libc::ioctl(pipe.read.as_raw_fd(), libc::FIONBIO, &on);
|
|
|
|
}
|
2019-08-18 18:49:20 +03:00
|
|
|
Ok(Self {
|
|
|
|
spawned_funcs: Mutex::new(VecDeque::new()),
|
|
|
|
write: Mutex::new(pipe.write),
|
|
|
|
read: Mutex::new(pipe.read),
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
fn spawn_impl(&self, f: SpawnFunc) {
|
|
|
|
use std::io::Write;
|
|
|
|
|
|
|
|
self.spawned_funcs.lock().unwrap().push_back(f);
|
|
|
|
self.write.lock().unwrap().write(b"x").ok();
|
|
|
|
}
|
|
|
|
|
fix a starvation issue on linux/x11 systems
The `SpawnQueue::run_impl` would loop until it had exhausted
all queued items. This prevents returning to the main loop
and resulted in the UI hanging while eg: `yes` was running,
and could also block accepting keyboard input, which is
pretty bad.
In addition, the queue implementation could fill up a pipe
and block the write side while it held a lock, which in
turn would prevent the read side from making room for the
write to succeed!
This commit changes the behavior on linux to change the wakeup
behavior of the queue from having a 1:1 relationship between
enqueue:wakeup to n:m where n and m are both >= 1. This is
sufficient to wake a sleeping gui thread. The gui thread
can then pop and process a single item at a time, interleaved
with dispatching the gui events.
The result is a bit more responsive, however, there is no
backpressure from the gui to the read side, so if the read
side is eating 2MB/s of data and the GUI side is processing
less than this, then an interrupt signal may still take a
few seconds to take effect.
I have mixed feelings about adding backpressure, because
I'm not sure that it is worth actually rendering all of
the parsed output text when there is a lot of it.
I need to follow up and verify these changes on macOS
and Windows too.
Refs: https://github.com/wez/wezterm/issues/65
2019-11-22 03:43:08 +03:00
|
|
|
fn run_impl(&self) -> bool {
|
|
|
|
// On linux we only ever process one at at time, so that
|
|
|
|
// we can return to the main loop and process messages
|
|
|
|
// from the X server
|
2019-08-18 18:49:20 +03:00
|
|
|
use std::io::Read;
|
fix a starvation issue on linux/x11 systems
The `SpawnQueue::run_impl` would loop until it had exhausted
all queued items. This prevents returning to the main loop
and resulted in the UI hanging while eg: `yes` was running,
and could also block accepting keyboard input, which is
pretty bad.
In addition, the queue implementation could fill up a pipe
and block the write side while it held a lock, which in
turn would prevent the read side from making room for the
write to succeed!
This commit changes the behavior on linux to change the wakeup
behavior of the queue from having a 1:1 relationship between
enqueue:wakeup to n:m where n and m are both >= 1. This is
sufficient to wake a sleeping gui thread. The gui thread
can then pop and process a single item at a time, interleaved
with dispatching the gui events.
The result is a bit more responsive, however, there is no
backpressure from the gui to the read side, so if the read
side is eating 2MB/s of data and the GUI side is processing
less than this, then an interrupt signal may still take a
few seconds to take effect.
I have mixed feelings about adding backpressure, because
I'm not sure that it is worth actually rendering all of
the parsed output text when there is a lot of it.
I need to follow up and verify these changes on macOS
and Windows too.
Refs: https://github.com/wez/wezterm/issues/65
2019-11-22 03:43:08 +03:00
|
|
|
if let Some(func) = self.pop_func() {
|
2019-08-18 18:49:20 +03:00
|
|
|
func();
|
|
|
|
|
|
|
|
let mut byte = [0u8];
|
|
|
|
self.read.lock().unwrap().read(&mut byte).ok();
|
fix a starvation issue on linux/x11 systems
The `SpawnQueue::run_impl` would loop until it had exhausted
all queued items. This prevents returning to the main loop
and resulted in the UI hanging while eg: `yes` was running,
and could also block accepting keyboard input, which is
pretty bad.
In addition, the queue implementation could fill up a pipe
and block the write side while it held a lock, which in
turn would prevent the read side from making room for the
write to succeed!
This commit changes the behavior on linux to change the wakeup
behavior of the queue from having a 1:1 relationship between
enqueue:wakeup to n:m where n and m are both >= 1. This is
sufficient to wake a sleeping gui thread. The gui thread
can then pop and process a single item at a time, interleaved
with dispatching the gui events.
The result is a bit more responsive, however, there is no
backpressure from the gui to the read side, so if the read
side is eating 2MB/s of data and the GUI side is processing
less than this, then an interrupt signal may still take a
few seconds to take effect.
I have mixed feelings about adding backpressure, because
I'm not sure that it is worth actually rendering all of
the parsed output text when there is a lot of it.
I need to follow up and verify these changes on macOS
and Windows too.
Refs: https://github.com/wez/wezterm/issues/65
2019-11-22 03:43:08 +03:00
|
|
|
true
|
|
|
|
} else {
|
|
|
|
false
|
2019-08-18 18:49:20 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#[cfg(all(unix, not(target_os = "macos")))]
|
|
|
|
impl Evented for SpawnQueue {
|
|
|
|
fn register(
|
|
|
|
&self,
|
|
|
|
poll: &Poll,
|
|
|
|
token: Token,
|
|
|
|
interest: Ready,
|
|
|
|
opts: PollOpt,
|
|
|
|
) -> std::io::Result<()> {
|
|
|
|
EventedFd(&self.read.lock().unwrap().as_raw_fd()).register(poll, token, interest, opts)
|
|
|
|
}
|
|
|
|
|
|
|
|
fn reregister(
|
|
|
|
&self,
|
|
|
|
poll: &Poll,
|
|
|
|
token: Token,
|
|
|
|
interest: Ready,
|
|
|
|
opts: PollOpt,
|
|
|
|
) -> std::io::Result<()> {
|
|
|
|
EventedFd(&self.read.lock().unwrap().as_raw_fd()).reregister(poll, token, interest, opts)
|
|
|
|
}
|
|
|
|
|
|
|
|
fn deregister(&self, poll: &Poll) -> std::io::Result<()> {
|
|
|
|
EventedFd(&self.read.lock().unwrap().as_raw_fd()).deregister(poll)
|
|
|
|
}
|
|
|
|
}
|
2019-08-18 18:57:07 +03:00
|
|
|
|
|
|
|
#[cfg(target_os = "macos")]
|
|
|
|
impl SpawnQueue {
|
|
|
|
fn new_impl() -> Fallible<Self> {
|
|
|
|
let spawned_funcs = Mutex::new(VecDeque::new());
|
|
|
|
|
|
|
|
let observer = unsafe {
|
|
|
|
CFRunLoopObserverCreate(
|
|
|
|
std::ptr::null(),
|
|
|
|
kCFRunLoopAllActivities,
|
|
|
|
1,
|
|
|
|
0,
|
|
|
|
SpawnQueue::trigger,
|
|
|
|
std::ptr::null_mut(),
|
|
|
|
)
|
|
|
|
};
|
|
|
|
unsafe {
|
|
|
|
CFRunLoopAddObserver(CFRunLoopGetMain(), observer, kCFRunLoopCommonModes);
|
|
|
|
}
|
|
|
|
|
|
|
|
Ok(Self { spawned_funcs })
|
|
|
|
}
|
|
|
|
|
2019-11-12 07:23:38 +03:00
|
|
|
extern "C" fn trigger(
|
|
|
|
_observer: *mut __CFRunLoopObserver,
|
|
|
|
_: CFRunLoopActivity,
|
|
|
|
_: *mut std::ffi::c_void,
|
|
|
|
) {
|
2019-08-18 18:57:07 +03:00
|
|
|
SPAWN_QUEUE.run();
|
|
|
|
}
|
|
|
|
|
|
|
|
fn spawn_impl(&self, f: SpawnFunc) {
|
|
|
|
self.spawned_funcs.lock().unwrap().push_back(f);
|
|
|
|
unsafe {
|
|
|
|
CFRunLoopWakeUp(CFRunLoopGetMain());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
fix a starvation issue on linux/x11 systems
The `SpawnQueue::run_impl` would loop until it had exhausted
all queued items. This prevents returning to the main loop
and resulted in the UI hanging while eg: `yes` was running,
and could also block accepting keyboard input, which is
pretty bad.
In addition, the queue implementation could fill up a pipe
and block the write side while it held a lock, which in
turn would prevent the read side from making room for the
write to succeed!
This commit changes the behavior on linux to change the wakeup
behavior of the queue from having a 1:1 relationship between
enqueue:wakeup to n:m where n and m are both >= 1. This is
sufficient to wake a sleeping gui thread. The gui thread
can then pop and process a single item at a time, interleaved
with dispatching the gui events.
The result is a bit more responsive, however, there is no
backpressure from the gui to the read side, so if the read
side is eating 2MB/s of data and the GUI side is processing
less than this, then an interrupt signal may still take a
few seconds to take effect.
I have mixed feelings about adding backpressure, because
I'm not sure that it is worth actually rendering all of
the parsed output text when there is a lot of it.
I need to follow up and verify these changes on macOS
and Windows too.
Refs: https://github.com/wez/wezterm/issues/65
2019-11-22 03:43:08 +03:00
|
|
|
fn run_impl(&self) -> bool {
|
|
|
|
let mut did_any = false;
|
2019-08-18 18:57:07 +03:00
|
|
|
while let Some(func) = self.pop_func() {
|
|
|
|
func();
|
fix a starvation issue on linux/x11 systems
The `SpawnQueue::run_impl` would loop until it had exhausted
all queued items. This prevents returning to the main loop
and resulted in the UI hanging while eg: `yes` was running,
and could also block accepting keyboard input, which is
pretty bad.
In addition, the queue implementation could fill up a pipe
and block the write side while it held a lock, which in
turn would prevent the read side from making room for the
write to succeed!
This commit changes the behavior on linux to change the wakeup
behavior of the queue from having a 1:1 relationship between
enqueue:wakeup to n:m where n and m are both >= 1. This is
sufficient to wake a sleeping gui thread. The gui thread
can then pop and process a single item at a time, interleaved
with dispatching the gui events.
The result is a bit more responsive, however, there is no
backpressure from the gui to the read side, so if the read
side is eating 2MB/s of data and the GUI side is processing
less than this, then an interrupt signal may still take a
few seconds to take effect.
I have mixed feelings about adding backpressure, because
I'm not sure that it is worth actually rendering all of
the parsed output text when there is a lot of it.
I need to follow up and verify these changes on macOS
and Windows too.
Refs: https://github.com/wez/wezterm/issues/65
2019-11-22 03:43:08 +03:00
|
|
|
did_any = true;
|
2019-08-18 18:57:07 +03:00
|
|
|
}
|
fix a starvation issue on linux/x11 systems
The `SpawnQueue::run_impl` would loop until it had exhausted
all queued items. This prevents returning to the main loop
and resulted in the UI hanging while eg: `yes` was running,
and could also block accepting keyboard input, which is
pretty bad.
In addition, the queue implementation could fill up a pipe
and block the write side while it held a lock, which in
turn would prevent the read side from making room for the
write to succeed!
This commit changes the behavior on linux to change the wakeup
behavior of the queue from having a 1:1 relationship between
enqueue:wakeup to n:m where n and m are both >= 1. This is
sufficient to wake a sleeping gui thread. The gui thread
can then pop and process a single item at a time, interleaved
with dispatching the gui events.
The result is a bit more responsive, however, there is no
backpressure from the gui to the read side, so if the read
side is eating 2MB/s of data and the GUI side is processing
less than this, then an interrupt signal may still take a
few seconds to take effect.
I have mixed feelings about adding backpressure, because
I'm not sure that it is worth actually rendering all of
the parsed output text when there is a lot of it.
I need to follow up and verify these changes on macOS
and Windows too.
Refs: https://github.com/wez/wezterm/issues/65
2019-11-22 03:43:08 +03:00
|
|
|
did_any
|
2019-08-18 18:57:07 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
pub struct SpawnQueueExecutor;
|
|
|
|
impl BasicExecutor for SpawnQueueExecutor {
|
|
|
|
fn execute(&self, f: SpawnFunc) {
|
|
|
|
SPAWN_QUEUE.spawn(f)
|
|
|
|
}
|
|
|
|
}
|