Hacker Newsnew | past | comments | ask | show | jobs | submit | Dykam's commentslogin

I'm pretty sure of the same, and that feature actually leaks into the implementation. Right after the initial introduction of the current Github Actions, we translated some Azure Devops scripts to Actions and a lot of the structure and most keywords where nearly identical. As well as the interface when running the CI.


As far as I'm aware, it's the development of Kestrel which pushed the introduction of ref/Span etc. Due to it Kestrel has seen quite a large speedup, it being one of the fastest HTTP servers nowadays. ref/Span allowed them to make the core almost allocation free, together with using vectorized operations (SIMD ) for parsing the request.


Which is a shame, because zero-knowledge actually can mean something. But it's yet another term with actual value hijacked for marketing.


Kind of like optimistic concurrency? "Lets try, we'll retry on failure".


It doesn't look like it's a full retry, atleast not for critical sections.

From what I can tell you do three things;

A) you can define a critical section which must run atomically in respect to the CPU core moves

B) if the critical section is interrupted you can define a callback or restart the section (meaning the section can be safely repeated)

C) you can define a single operation to commit (ie, updating a pointer)

You can certainly build a "retry on failure" method using this, CPU moves are rare so it's unlikely to fail the second time.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: