Live data from Hacker News

Viewing profile — ibraheemdev

ibraheemdev

HN member
Joined
Fri, Sep 11, 2020, 4:30 PM UTC
HN karma
4,933
Public activity
790 items

About ibraheemdev

Software developer interested in building fast, concurrent, and robust systems.

Contact ibraheem@ibraheem.ca.

Recent public activity

  1. comment
    Comment #47907661

    Not the runtime per se, but cooperative scheduling has the advantage that tasks do not yield at adverse code points, e.g., right before giving up a lock, or performing an I/O reque…

  2. comment
    Comment #47904287

    > OS threads are expensive: an operating system thread typically reserves a megabyte of stack space Why is reserving a megabyte of stack space "expensive"? > and takes roughly a mi…

  3. story
    Astral to Join OpenAI

    https://openai.com/index/openai-to-acquire-astral/

  4. story
  5. comment
    Comment #45357480

    It does make a difference of course if you're running fetch_max from multiple threads, adding a load fast-path introduces a race condition.

  6. comment
    Comment #45217912

    pip, PDM, and uv already support PEP751 [0] and were involved in the design process. [0]: https://discuss.python.org/t/community-adoption-of-pylock-to...

  7. comment
    Comment #45088632

    I did not claim that x86 provides sequential consistency in general, I made that claim only for RMW operations. Sequentially consistent stores are typically lowered to an XCHG inst…

  8. comment
    Comment #45088148

    Yes, what I meant was that the same instruction is generated by the compiler, regardless if the RMW operation is performed with relaxed or sequentially consistent ordering, because…

  9. comment
    Comment #45087574

    I'm referring to the performance implications of the hardware instruction, not the programming language semantics. Incrementing or decrementing the reference count is going to requ…

  10. comment
    Comment #45084954

    > There is no way the shared_ptr is using the expensive sequentially consistent atomic operations. All RMW operations have sequentially consistent semantics on x86. It's not exactl…

  11. comment
    Comment #44967347

    > ParkingLot just uses pthread mutex and cond. That's interesting, I'm more familiar with the Rust parking-lot implementation, which uses futex on Linux [0]. > Sure that uses futex…

  12. comment
    Comment #44966992

    > And futexes aren’t the only way to get there. Alternatives: > - thin locks (what JVMs use) > - ParkingLot (a futex-like primitive that works entirely in userland and doesn’t requ…

  13. comment
    Comment #42945862

    > The message has some weird mentions in (alloc565), but the actual useful information is there: a pointer is dangling. The allocation ID is actually very useful for debugging. You…

  14. story
  15. comment
    Comment #42056132

    > Every single Future you look at will look like this, That's not true. A Future is supposed to schedule itself to be woken up again when it's ready . This Future schedules it to b…

  16. comment
    Comment #41811639

    It's quite common for concurrent algorithms to only implement a subset of operations. For example forgoing, removal or iteration. It's also common to put limitations on the data st…

  17. comment
    Comment #41803131

    Looks very interesting, but seems to serve a pretty different use case: > This is an ordered data structure, and supports very high throughput iteration over lexicographically sort…

  18. story
  19. comment
    Comment #41241012

    Java atomics are actually sequentially consistent. C# relaxes this to acquire/release. Though the general concept of happens-before is still immensely useful for learning atomics a…

  20. story
  21. story
  22. comment
    Comment #38935823

    Formatting the if onto a single line gets you most of the way there. if err != nil { return err }

  23. comment
    Comment #37185855

    Yeah you're right regarding signal handlers (though I'm not sure the windows equivalent), and I was planning on adding a note about the alternative. The main thing I wanted to poin…

  24. story
  25. story