| Age | Commit message (Collapse) | Author |
|---|
|
This is all forcing clarifying a bunch of details I'm going to
keep putting off and just kicking around to try keep functional
for now.
|
|
Just adding some missing thunk_{mid,end}() return value filters,
which highlights some small optimization opportunities where
these instances aren't being reused.
Still on the fence about this life-cycle approach and naming
though.
|
|
Udpate thunk usage througout to explicitly control thunk instance
lifecycles from calleees according to new model.
This enables discarding a bunch of the per-object dispatch
thunks, eliminates some thunk leaks, and I think generally makes
the code more expressive and clear about what's going on.
Keep in mind this is all experimental and and I'm not spending a
whole lot of time on this, it's mostly a toy and exploring some
different programming styles I'd never really consider for
production/real work.
Though it actually has some interesting properties, and produces
some surprisingly succinct and readable listings at times once
you have the cumbersome building blocks in place. Especially for
non-daemon programs where you can basically either log+ignore
errors or treat them as fatal, I think this programming style
might actually have its place.
|
|
This is currently very hacky and unfinished, but does enough for
some performance comparisons against a zstd-using journalctl --verify
that has been hacked to return early after the first pass.
It's currently rather leaky, the whole per-object-dispatch thingy
is illuminating a thunk_h shortcoming and forcing addressing the
issue... soon.
|
