Skip to content
This repository has been archived by the owner on Feb 3, 2023. It is now read-only.

Tracing (Internal) Signals #732

Merged
merged 29 commits into from
Dec 14, 2018
Merged

Tracing (Internal) Signals #732

merged 29 commits into from
Dec 14, 2018

Conversation

maackle
Copy link
Member

@maackle maackle commented Dec 6, 2018

  • Wrap Instance and Context signal senders in Option rather than initializing with broken channels
  • Add Signal struct with Internal variant
  • Emit Signal::Internal for most Actions (all but InitApplication)
  • Test for said emitting
  • Adds utility for replacing history.len() checks with a signal receiver

- Wrap signal senders in Option rather than initializing with broken channels
- Add Signal struct with Internal variant
- Emit Signal::Internal for most Actions (all but InitApplication)
- Test for said emitting
- Adds utility for replacing history.len() checks with a signal receiver
@maackle maackle changed the title [WIP] Signals internal Tracing (Internal) Signals Dec 11, 2018
core/src/instance.rs Outdated Show resolved Hide resolved
core/src/nucleus/actions/build_validation_package.rs Outdated Show resolved Hide resolved
core/src/instance.rs Outdated Show resolved Hide resolved
core/src/instance.rs Outdated Show resolved Hide resolved
Copy link
Member

@zippy zippy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work! This is great stuff. Approved but I would like to see the printlns removed...

@@ -72,7 +72,11 @@ fn bootstrap_from_config(path: &str) -> Result<Container, HolochainError> {
config
.check_consistency()
.map_err(|string| HolochainError::ConfigError(string))?;
Container::try_from(&config)
let mut container = Container::from_config(config).with_signal_handler(|sig| {
println!("WE GET SIGNAL:\n{:?}", sig);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure I like the println here. I think this should be moved into a bonafide test.

});
self.signal_thread = Some(signal_thread);
} else {
println!("Warning: no signal handler was set!");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

println also, perhaps this function should return a Result?

// @NB: if the Instance constructor ever changes such that it can accept a SyncSender rather than
// spitting out a Receiver, we can just clone that Sender instead of gathering the receivers
let signal_rx = combine_receivers(signal_rxs);
self.spawn_signal_thread(signal_rx);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if spawn_signal_thread returns a Result then this could just have a ?

// @NB: these three getters smell bad because previously Instance and Context had SyncSenders
// rather than Option<SyncSenders>, but these would be initialized by default to broken channels
// which would panic if `send` was called upon them. These `expect`s just bring more visibility to
// that potential failure mode.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice!

@maackle
Copy link
Member Author

maackle commented Dec 14, 2018

I realized that specifying a signal handler in the container is a bit overkill. It's far simpler to set up a channel outside the Container and pass in the SyncSender, and let the Container invoker do whatever they want with the receiver, including possibly creating an hander loop. This also obviates the need to combine the receivers from each Instance (which required spinning up a bunch of extra threads), since now the SyncSender can just get cloned for each new Instance that needs to send a signal.

I would appreciate a look at the new changes @zippy and @lucksus.

@codecov
Copy link

codecov bot commented Dec 14, 2018

Codecov Report

Merging #732 into develop will increase coverage by 0.31%.
The diff coverage is 85.49%.

Impacted file tree graph

@@             Coverage Diff             @@
##           develop     #732      +/-   ##
===========================================
+ Coverage    72.37%   72.67%   +0.31%     
===========================================
  Files          146      147       +1     
  Lines         4947     5005      +58     
===========================================
+ Hits          3580     3637      +57     
- Misses        1367     1368       +1
Impacted Files Coverage Δ
core/src/nucleus/actions/validate.rs 73.34% <ø> (ø) ⬆️
container_api/src/interface.rs 68.75% <ø> (ø) ⬆️
container/src/main.rs 0% <ø> (ø) ⬆️
...re/src/nucleus/actions/build_validation_package.rs 69.45% <ø> (ø) ⬆️
core/src/workflows/handle_custom_direct_message.rs 0% <0%> (ø) ⬆️
core/src/nucleus/ribosome/api/update_entry.rs 0% <0%> (ø) ⬆️
core/src/network/actions/custom_send.rs 0% <0%> (ø) ⬆️
core/src/nucleus/ribosome/api/remove_entry.rs 0% <0%> (ø) ⬆️
core/src/nucleus/ribosome/api/call.rs 51.79% <0%> (ø) ⬆️
core/src/dht/actions/hold.rs 57.15% <100%> (ø) ⬆️
... and 22 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a32b7db...51e1ff8. Read the comment docs.

@codecov
Copy link

codecov bot commented Dec 14, 2018

Codecov Report

Merging #732 into develop will increase coverage by 0.3%.
The diff coverage is 85.49%.

Impacted file tree graph

@@            Coverage Diff             @@
##           develop     #732     +/-   ##
==========================================
+ Coverage    72.64%   72.94%   +0.3%     
==========================================
  Files          145      146      +1     
  Lines         4922     4980     +58     
==========================================
+ Hits          3575     3632     +57     
- Misses        1347     1348      +1
Impacted Files Coverage Δ
core/src/nucleus/actions/validate.rs 73.34% <ø> (ø) ⬆️
container_api/src/interface.rs 68.75% <ø> (ø) ⬆️
container/src/main.rs 0% <ø> (ø) ⬆️
...re/src/nucleus/actions/build_validation_package.rs 69.45% <ø> (ø) ⬆️
core/src/workflows/handle_custom_direct_message.rs 0% <0%> (ø) ⬆️
core/src/nucleus/ribosome/api/update_entry.rs 0% <0%> (ø) ⬆️
core/src/network/actions/custom_send.rs 0% <0%> (ø) ⬆️
core/src/nucleus/ribosome/api/remove_entry.rs 0% <0%> (ø) ⬆️
core/src/nucleus/ribosome/api/call.rs 51.79% <0%> (ø) ⬆️
core/src/dht/actions/hold.rs 61.91% <100%> (+4.77%) ⬆️
... and 22 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d90b968...c48cc35. Read the comment docs.

Copy link
Collaborator

@lucksus lucksus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still good :)
I started refactoring Context and adding a builder. I should base my stuff off of this. Either we merge this soon or I will just merge this into my branch...

@zippy
Copy link
Member

zippy commented Dec 14, 2018

I'm mildly in favor of just merging this before we figure out the windows problem and adding it to the list. However I did notice something weird. Look at line 848 of https://travis-ci.com/holochain/holochain-rust/jobs/165253486

why are there those compiler warnings? I don't see them when I run holochain-cmd tests locally.

@lucksus lucksus merged commit db7117f into develop Dec 14, 2018
@lucksus lucksus removed the review label Dec 14, 2018
@maackle maackle deleted the signals-internal branch December 14, 2018 20:21
@maackle maackle mentioned this pull request Dec 15, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants