mirror of
https://github.com/Nanaloveyuki/BitLogger.git
synced 2026-07-24 08:52:35 +00:00
Nanaloveyuki
88 lines
3.2 KiB
Markdown
88 lines
3.2 KiB
Markdown
---
|
|
name: runtime-sink-close
|
|
group: api
|
|
category: runtime
|
|
update-time: 20260707
|
|
description: Close a RuntimeSink and report whether the concrete close path succeeded.
|
|
key-word:
|
|
- runtime
|
|
- sink
|
|
- lifecycle
|
|
- public
|
|
---
|
|
|
|
## Runtime-sink-close
|
|
|
|
Close a `RuntimeSink`. This is the direct runtime sink lifecycle API behind configured logger close behavior.
|
|
|
|
### Interface
|
|
|
|
```moonbit
|
|
pub fn RuntimeSink::close(self : RuntimeSink) -> Bool {
|
|
```
|
|
|
|
#### input
|
|
|
|
- `self : RuntimeSink` - Runtime sink whose underlying resources should be closed.
|
|
|
|
#### output
|
|
|
|
- `Bool` - Whether the concrete runtime sink reported a successful close path.
|
|
|
|
### Explanation
|
|
|
|
Detailed rules explaining key parameters and behaviors
|
|
|
|
- Plain console-style runtime sinks return `true` because they do not have a meaningful close step here.
|
|
- Plain file runtime sinks forward directly to `FileSink::close()`.
|
|
- Queued file runtime sinks now follow the same safe teardown path as `file_close()`: they first try to drain the queue, then flush the wrapped file sink, then close it.
|
|
- On `QueuedFile`, the returned `Bool` is `true` only when that whole teardown path succeeds without introducing new file failures.
|
|
- Queue-wrapped console-style runtime sinks also use drain-first teardown.
|
|
- For `QueuedConsole`, `QueuedJsonConsole`, and `QueuedTextConsole`, `close()` consumes pending queue items before reporting success.
|
|
- Because these wrapped console-style sinks do not expose an additional close-failure channel, success for these variants means the backlog was drained to zero.
|
|
- This method is the direct sink-level API used by `ConfiguredLogger::close(...)`.
|
|
- For file-backed runtime sinks, later `close()` calls return `false` after the handle has already been cleared.
|
|
|
|
### How to Use
|
|
|
|
Here are some specific examples provided.
|
|
|
|
#### When Need Direct Runtime Teardown
|
|
|
|
When code owns a `RuntimeSink` and should release its underlying resources:
|
|
```moonbit
|
|
ignore(sink.close())
|
|
```
|
|
|
|
In this example, sink teardown happens without going through a logger wrapper.
|
|
|
|
#### When Need To Observe Close Outcome
|
|
|
|
When application code wants a success flag from the direct runtime sink:
|
|
```moonbit
|
|
let closed = sink.close()
|
|
```
|
|
|
|
In this example, callers can branch on the reported close result.
|
|
|
|
### Error Case
|
|
|
|
e.g.:
|
|
- If the runtime sink shape has no real close action, the method may still return `true` as a no-op success.
|
|
|
|
- If a file-backed runtime sink was already closed earlier through this sink or another facade sharing the same underlying state, a later close attempt returns `false`.
|
|
|
|
- If callers know they are working with a direct `FileSink`, `FileSink::close()` is the narrower API.
|
|
|
|
- On queued file sinks, `true` still does not mean the records are guaranteed to be durable beyond what the current backend can report; it means the queue-drain, file-flush, and file-close path completed without a newly observed file failure.
|
|
|
|
- On queued non-file sinks, `true` means the queued backlog was consumed before teardown completed.
|
|
|
|
### Notes
|
|
|
|
1. Use this helper when code is managing a `RuntimeSink` value directly.
|
|
|
|
2. Generic `close()` is now safe for queue-backed runtime sinks and no longer skips queued records silently.
|
|
|
|
3. `ConfiguredLogger::close(...)` is the higher-level wrapper for config-built loggers.
|