Live data from Hacker News

Viewing profile — coreytabaka

coreytabaka

HN member
Joined
Fri, Oct 05, 2018, 10:25 PM UTC
HN karma
25
Public activity
18 items

About coreytabaka

No profile information was provided.

Recent public activity

  1. 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! :)…

  2. 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…

  3. comment
    Comment #19646742

    No, that's based on the deprecated multi-level round-robin scheduler, which we find tremendously amusing. :)

  4. comment
    Comment #19646642

    It does imply that. Multiple concurrent scheduling algorithms is nothing new, Linux and MacOS both support per-thread algorithm selection.

  5. 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...

  6. 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…

  7. 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…

  8. 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…

  9. 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…

  10. 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.

  11. comment
    Comment #18153926

    Thanks! MessagePack is one of the influences.

  12. 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...…

  13. 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…

  14. 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…

  15. 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…

  16. 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.

  17. 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…

  18. comment
    Comment #18152262

    Primary author and maintainer here! Happy to answer any questions anyone has.