Viewing profile — coreytabaka
coreytabaka
HN member- Joined
- Fri, Oct 05, 2018, 10:25 PM UTC
- HN karma
- 25
- Public activity
- 18 items
- HN profile
- View on Hacker News ↗
About coreytabaka
No profile information was provided.
Recent public activity
-
comment
Comment #19649116
IO scheduling is a separate problem, though it shares the same fundamental properties. The same goes for network packet scheduling. All of these are ongoing efforts. Stay tuned! :)…
-
comment
Comment #19648474
A simple hierarchy: when there is deadline work to do that work takes precedence, fair work gets the rest of the time. This is effective because deadline work has bounded execution…
-
comment
Comment #19646742
No, that's based on the deprecated multi-level round-robin scheduler, which we find tremendously amusing. :)
-
comment
Comment #19646642
It does imply that. Multiple concurrent scheduling algorithms is nothing new, Linux and MacOS both support per-thread algorithm selection.
-
comment
Comment #18156630
The library is transport agnostic. There is a Reader/Writer abstraction to adapt to any transport you like. https://github.com/google/libnop/blob/master/docs/getting-st...
-
comment
Comment #18154251
In most cases the context provides enough information: void Baz(Bar*); void Baz(const Bar&); void Foo(Bar* mutable_bar) { Baz(*mutable_bar); // Not mutated. } void Foo(Bar* mutable…
-
comment
Comment #18154169
For the most part the optimization works well. The more subtle issue is that the union trick used by the endian utilities is not compatible with constexpr expressions. There are so…
-
comment
Comment #18154079
The table approach is fairly flexible. Both Protos and FlatBuffers do more or less functionally similar things. What specific deficiency do you see? Take a look at the binary forma…
-
comment
Comment #18153951
Yes! Hopefully C++20 or C++25-ish will provide better alternatives for compile-time reflection. Don't forget that libnop also has NOP_EXTERNAL_STRUCTURE (and friends) to decouple t…
-
comment
Comment #18153942
Supporting embedded platforms is one of the objectives of the library. Feel free to open a ticket on github if you have any further questions.
-
comment
Comment #18153926
Thanks! MessagePack is one of the influences.
-
comment
Comment #18153921
I tried to keep it C++11, but generalized lambdas are critical in important use cases (see nop::Variant). Besides, GCC and Clang have solid C++14 support. C++17 is another story...…
-
comment
Comment #18153908
Since you mention it, check out the experimental RPC support: https://github.com/google/libnop/blob/master/examples/interf... https://github.com/google/libnop/blob/master/include/n…
-
comment
Comment #18153329
This argument comes up a lot within Google. The style guide is revisited frequently (for example =delete in the public section is now the standard for disabling copy and/or move/as…
-
comment
Comment #18153261
Thanks for considering using libnop! This library works well in an embedded context. I've personally used it on Cortex-M class micro controller firmware. The serializer/deserialize…
-
comment
Comment #18152501
unique_ptr and nop::Optional > is on the way. shared_ptr opens up the ability to create cycles, which are not supported yet.
-
comment
Comment #18152307
It means not currently an officially supported project. Most open source releases of internal code start out this way and may or may not become officially supported. It is differen…
-
comment
Comment #18152262
Primary author and maintainer here! Happy to answer any questions anyone has.