Oh neat, just realized `log` + `bumpalo` probably work really well together! Each time a message is created it can be stored in the bump allocator. Then every n messages, or when `Log::flush` is called we take a lock on stdout, write all messages, and reset the allocator!
-
Show this thread
-
I believe there's a way we can use this to effectively do allocation-free logging. Meaning: the cost of initializing the bump allocator is amortized by the duration of the program. Probably worth testing out!
1 reply 0 retweets 5 likesShow this thread -
Tested this and it turns out Bumpalo makes use of `Cell` under the hood to keep track of access (makes sense!) However this means we cannot use this across threads unless we wrap it in a Mutex.. which is exactly what we were trying to avoid!
1 reply 0 retweets 0 likesShow this thread -
The reason why it needs to be thread-safe is b/c `log::Log: Send + Sync` https://docs.rs/log/0.4.8/log/trait.Log.html … It seems the *right* solution here would be to build a thread-safe bump allocator. It should be possible to build a lock-free version. But not even going to attempt building it hah.
2 replies 0 retweets 1 likeShow this thread -
Replying to @yoshuawuyts
This thing comes to mind: https://github.com/japaric/cortex-m-funnel … It creates an SPSC logging queue for each interrupt level (~ thread), and the idle loop is expected to drain each one. This keeps everything lockless even when the hardware has no atomics.
1 reply 0 retweets 2 likes -
Replying to @sheevink
Ohh, yes of course! Should be fairly straight forward to build with crossbeam's queues! Out of curiosity: what do you mean by "idle loop" here?
1 reply 0 retweets 0 likes -
Replying to @yoshuawuyts
Embedded programs usually have an "idle loop" which runs when nothing else needs doing (ie. there are no pending interrupts that need to be served). This is the lowest-priority code that runs in an application. Often this loop is just "loop { wait for interrupt }".
1 reply 1 retweet 2 likes
Ohhh, I like this a lot! Browser have a similar concept -- `RequestIdleCallback`. This allows scheduling work during idle time OR if a duration has elapsed. I've been wondering for a while now if we could bring this to async runtimes as well; think it could make sense! Ty! :D
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.