Allow get_persistence_condvar_value outside of tests

[MaxFangX]

Summary

Allow usage of ChannelManager::get_persistence_condvar_value outside of tests.

Motivation

Polling

We implemented a Tokio-based background processor that runs entirely in a single task and which doesn't need its own thread. Accordingly, we made our entire node single-threaded. However, the only exposed methods for determining whether a ChannelManager has a persistable update require blocking (await_persistable_update, await_persistable_update_timeout), and the only way to simulate 'polling' is to do something like the following:

let needs_persist = channel_manager.await_persistable_update_timeout(Duration::from_millis(10));

Which is really just a jank way of doing what we really want: to inspect the value inside the persistence condvar. This PR removes the cfgs on get_persistence_condvar_value and allows us to poll for persistence updates in a completely non-blocking manner.

Performance

This impacts performance too: with a polling frequency of 100ms (the default in rust-lightning background processor) and a poll timeout of 10ms, using await_persistable_update_timeout as above causes our single-threaded node to be blocked and unable to do anything else about 10% of the time.

[TheBlueMatt]

You may be interested in #1657. Would that address your goal here?

[MaxFangX]

That's perfect - both the solution and the timing lol. Right now, we are 'polling' await_persistable_update_timeout every time a tokio::time::interval ticks. get_persistable_update_future allows us to use the Future directly in our select! event loop and get rid of the polling interval. I'll close this PR and wait for #1657.

[MaxFangX]

Summary

Allow usage of ChannelManager::get_persistence_condvar_value outside of tests.

Motivation

Polling

We implemented a Tokio-based background processor that runs entirely in a single task and which doesn't need its own thread. Accordingly, we made our entire node single-threaded. However, the only exposed methods for determining whether a ChannelManager has a persistable update require blocking (await_persistable_update, await_persistable_update_timeout), and the only way to simulate 'polling' is to do something like the following:

let needs_persist = channel_manager.await_persistable_update_timeout(Duration::from_millis(10));

Which is really just a jank way of doing what we really want: to inspect the value inside the persistence condvar. This PR removes the cfgs on get_persistence_condvar_value and allows us to poll for persistence updates in a completely non-blocking manner.

Performance

This impacts performance too: with a polling frequency of 100ms (the default in rust-lightning background processor) and a poll timeout of 10ms, using await_persistable_update_timeout as above causes our single-threaded node to be blocked and unable to do anything else about 10% of the time.

[TheBlueMatt]

You may be interested in #1657. Would that address your goal here?

[MaxFangX]

That's perfect - both the solution and the timing lol. Right now, we are 'polling' await_persistable_update_timeout every time a tokio::time::interval ticks. get_persistable_update_future allows us to use the Future directly in our select! event loop and get rid of the polling interval. I'll close this PR and wait for #1657.

[MaxFangX]

Summary

Allow usage of ChannelManager::get_persistence_condvar_value outside of tests.

Motivation

Polling

We implemented a Tokio-based background processor that runs entirely in a single task and which doesn't need its own thread. Accordingly, we made our entire node single-threaded. However, the only exposed methods for determining whether a ChannelManager has a persistable update require blocking (await_persistable_update, await_persistable_update_timeout), and the only way to simulate 'polling' is to do something like the following:

let needs_persist = channel_manager.await_persistable_update_timeout(Duration::from_millis(10));

Which is really just a jank way of doing what we really want: to inspect the value inside the persistence condvar. This PR removes the cfgs on get_persistence_condvar_value and allows us to poll for persistence updates in a completely non-blocking manner.

Performance

This impacts performance too: with a polling frequency of 100ms (the default in rust-lightning background processor) and a poll timeout of 10ms, using await_persistable_update_timeout as above causes our single-threaded node to be blocked and unable to do anything else about 10% of the time.

[TheBlueMatt]

You may be interested in #1657. Would that address your goal here?

[MaxFangX]

That's perfect - both the solution and the timing lol. Right now, we are 'polling' await_persistable_update_timeout every time a tokio::time::interval ticks. get_persistable_update_future allows us to use the Future directly in our select! event loop and get rid of the polling interval. I'll close this PR and wait for #1657.

[MaxFangX]

Summary

Allow usage of ChannelManager::get_persistence_condvar_value outside of tests.

Motivation

Polling

We implemented a Tokio-based background processor that runs entirely in a single task and which doesn't need its own thread. Accordingly, we made our entire node single-threaded. However, the only exposed methods for determining whether a ChannelManager has a persistable update require blocking (await_persistable_update, await_persistable_update_timeout), and the only way to simulate 'polling' is to do something like the following:

let needs_persist = channel_manager.await_persistable_update_timeout(Duration::from_millis(10));

Which is really just a jank way of doing what we really want: to inspect the value inside the persistence condvar. This PR removes the cfgs on get_persistence_condvar_value and allows us to poll for persistence updates in a completely non-blocking manner.

Performance

This impacts performance too: with a polling frequency of 100ms (the default in rust-lightning background processor) and a poll timeout of 10ms, using await_persistable_update_timeout as above causes our single-threaded node to be blocked and unable to do anything else about 10% of the time.

[TheBlueMatt]

You may be interested in #1657. Would that address your goal here?

[MaxFangX]

That's perfect - both the solution and the timing lol. Right now, we are 'polling' await_persistable_update_timeout every time a tokio::time::interval ticks. get_persistable_update_future allows us to use the Future directly in our select! event loop and get rid of the polling interval. I'll close this PR and wait for #1657.

[MaxFangX]

Summary

Allow usage of ChannelManager::get_persistence_condvar_value outside of tests.

Motivation

Polling

We implemented a Tokio-based background processor that runs entirely in a single task and which doesn't need its own thread. Accordingly, we made our entire node single-threaded. However, the only exposed methods for determining whether a ChannelManager has a persistable update require blocking (await_persistable_update, await_persistable_update_timeout), and the only way to simulate 'polling' is to do something like the following:

let needs_persist = channel_manager.await_persistable_update_timeout(Duration::from_millis(10));

Which is really just a jank way of doing what we really want: to inspect the value inside the persistence condvar. This PR removes the cfgs on get_persistence_condvar_value and allows us to poll for persistence updates in a completely non-blocking manner.

Performance

This impacts performance too: with a polling frequency of 100ms (the default in rust-lightning background processor) and a poll timeout of 10ms, using await_persistable_update_timeout as above causes our single-threaded node to be blocked and unable to do anything else about 10% of the time.

[TheBlueMatt]

You may be interested in #1657. Would that address your goal here?

[MaxFangX]

That's perfect - both the solution and the timing lol. Right now, we are 'polling' await_persistable_update_timeout every time a tokio::time::interval ticks. get_persistable_update_future allows us to use the Future directly in our select! event loop and get rid of the polling interval. I'll close this PR and wait for #1657.

[MaxFangX]

Summary

Allow usage of ChannelManager::get_persistence_condvar_value outside of tests.

Motivation

Polling

We implemented a Tokio-based background processor that runs entirely in a single task and which doesn't need its own thread. Accordingly, we made our entire node single-threaded. However, the only exposed methods for determining whether a ChannelManager has a persistable update require blocking (await_persistable_update, await_persistable_update_timeout), and the only way to simulate 'polling' is to do something like the following:

let needs_persist = channel_manager.await_persistable_update_timeout(Duration::from_millis(10));

Which is really just a jank way of doing what we really want: to inspect the value inside the persistence condvar. This PR removes the cfgs on get_persistence_condvar_value and allows us to poll for persistence updates in a completely non-blocking manner.

Performance

This impacts performance too: with a polling frequency of 100ms (the default in rust-lightning background processor) and a poll timeout of 10ms, using await_persistable_update_timeout as above causes our single-threaded node to be blocked and unable to do anything else about 10% of the time.

[TheBlueMatt]

You may be interested in #1657. Would that address your goal here?

[MaxFangX]

That's perfect - both the solution and the timing lol. Right now, we are 'polling' await_persistable_update_timeout every time a tokio::time::interval ticks. get_persistable_update_future allows us to use the Future directly in our select! event loop and get rid of the polling interval. I'll close this PR and wait for #1657.

[MaxFangX]

Summary

Allow usage of ChannelManager::get_persistence_condvar_value outside of tests.

Motivation

Polling

We implemented a Tokio-based background processor that runs entirely in a single task and which doesn't need its own thread. Accordingly, we made our entire node single-threaded. However, the only exposed methods for determining whether a ChannelManager has a persistable update require blocking (await_persistable_update, await_persistable_update_timeout), and the only way to simulate 'polling' is to do something like the following:

let needs_persist = channel_manager.await_persistable_update_timeout(Duration::from_millis(10));

Which is really just a jank way of doing what we really want: to inspect the value inside the persistence condvar. This PR removes the cfgs on get_persistence_condvar_value and allows us to poll for persistence updates in a completely non-blocking manner.

Performance

This impacts performance too: with a polling frequency of 100ms (the default in rust-lightning background processor) and a poll timeout of 10ms, using await_persistable_update_timeout as above causes our single-threaded node to be blocked and unable to do anything else about 10% of the time.

[TheBlueMatt]

You may be interested in #1657. Would that address your goal here?

[MaxFangX]

That's perfect - both the solution and the timing lol. Right now, we are 'polling' await_persistable_update_timeout every time a tokio::time::interval ticks. get_persistable_update_future allows us to use the Future directly in our select! event loop and get rid of the polling interval. I'll close this PR and wait for #1657.

[MaxFangX]

Summary

Allow usage of ChannelManager::get_persistence_condvar_value outside of tests.

Motivation

Polling

We implemented a Tokio-based background processor that runs entirely in a single task and which doesn't need its own thread. Accordingly, we made our entire node single-threaded. However, the only exposed methods for determining whether a ChannelManager has a persistable update require blocking (await_persistable_update, await_persistable_update_timeout), and the only way to simulate 'polling' is to do something like the following:

let needs_persist = channel_manager.await_persistable_update_timeout(Duration::from_millis(10));

Which is really just a jank way of doing what we really want: to inspect the value inside the persistence condvar. This PR removes the cfgs on get_persistence_condvar_value and allows us to poll for persistence updates in a completely non-blocking manner.

Performance

This impacts performance too: with a polling frequency of 100ms (the default in rust-lightning background processor) and a poll timeout of 10ms, using await_persistable_update_timeout as above causes our single-threaded node to be blocked and unable to do anything else about 10% of the time.

[TheBlueMatt]

You may be interested in #1657. Would that address your goal here?

[MaxFangX]

That's perfect - both the solution and the timing lol. Right now, we are 'polling' await_persistable_update_timeout every time a tokio::time::interval ticks. get_persistable_update_future allows us to use the Future directly in our select! event loop and get rid of the polling interval. I'll close this PR and wait for #1657.