Skip to content

Conversation

gabyx
Copy link

@gabyx gabyx commented Mar 16, 2024

@gabyx
Copy link
Author

gabyx commented Mar 16, 2024

Not really sure if that feature is needed: The use case was #35 :

  • Make the worker thread somehow stop processing records (not implemented)
  • Flush all pending stuff (till the crossbeam channels are empty) implemented
  • Output some prompt on letssay stderr.
  • Make the worker thread continue to process records.

So if we would have a term logger we could before prompting just use log.flush(...) and then show the prompt and wait for input etc...

@dpc
Copy link
Contributor

dpc commented Mar 17, 2024

Looks reasonable to me. Ping @Techcable as current maintainer.

Techcable added a commit to Techcable/slog-async that referenced this pull request Aug 9, 2025
Sends a message to the logging thread,
then blocks until the logger acknowledges it.
Contrast this to the busy-loop approach in slog-rs#36

Pinned to the branch used in PR #349,
so cannot be released until that PR is accepted.

Fixes issue slog-rs#35
Techcable added a commit to Techcable/slog-async that referenced this pull request Aug 9, 2025
Sends a message to the logging thread,
then blocks until the logger acknowledges it.
Contrast this to the busy-loop approach in slog-rs#36

Pinned to the branch used in PR #349,
so cannot be released until that PR is accepted.

Fixes issue slog-rs#35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants