#async
Give me true async for PHP 9.0
Time for a release Friday release: Bunny v0.6.0-alpha.1 is out with a host of changes since v0.5: https://github.com/jakubkulhan/bunny/releases/tag/v0.6.0-alpha.1
It's been a lot of fun doing this major rework on Bunny's internals into a full @reactphp client while using fibers internally to simplify the public API.
That's it for the benchmarking! You can find my implementation at http://github.com/anisse/lbzip2-rs/ ; it's very much PoC-quality code, so use at our own risks! I chose to manually spawn threads instead of using rayon or an async runtime; there are other things I'm not proud of, like busy-waiting instead of condvar for example. 14/N
SQLite async connection pool for high-performance
https://github.com/slaily/aiosqlitepool
#HackerNews #SQLite #async #connection #pool #high-performance #aiosqlitepool #database
C++ Coroutines Advanced: Converting std:future to asio:awaitable
https://www.ddhigh.com/en/2025/07/15/cpp-coroutine-future-to-awaitable/
#HackerNews #C++ #Coroutines #Advanced #std::future #asio:awaitable #programming #async #await #C++
To pin or to unpin, that is truly the question
What if your PHP functions could pause, resume, and remember where they left off, like little self-aware scripts? 
That’s what coroutines are for, and PHP gives you two tools to use them: Generators (since 5.5) and Fibers (in PHP 8.1).
I break it all down with real code, plus a hot potato metaphor you won’t forget:
https://doeken.org/blog/coroutines-in-php?utm_source=mastodon
JavaScript, wow!
I was under the impression that if a function returns a Promise, it never throws. Rather, in any case, it returns a Promise, rejected if the functions throws something.
But fetch() is a counter-example. Or this on the TypeScript playground:
The crucial thing is. My impression above is true for functions of the form
async f(...): Promise<...> { ... }
Just add the async in the playground to see the difference.
How I normally do #async external programs in my #commonLisp image #embeddableCommonLisp and #uiop (in the notes).
Originally I was writing Kittenette (Closette but for kittens) today, but I ended up wanting to individually treat external processes, especially from #ecl on its own first.
My example is particularly using #cat(1) as an external-process in-memory echo server.
Hope it helps someone. #programming #example
Yes "multi-processing" in the url is ~erroneous.
@noboilerplate THIS!
I think a lot of people inadvertently assume async #RustLang is so different from sync Rust, because the way it is - when in fact it's because of the (most popular) async runtime they're using.
We should look way more into alternative #async runtimes to #Tokio, e.g. smol:
https://floss.social/@janriemer/111669258656959538
#Smol allows you to use non-'static Futures by using a local executor:
https://floss.social/@janriemer/111669668856899636
It looks a lot more like "normal" #Rust.
C++OnSea 2025 SESSION ANNOUNCEMENT: Extending std::execution Further: Higher-Order Senders and the Shape of Asynchronous Programs by Robert Leahy
Register now at https://cpponsea.uk/tickets/
Faster Python: Concurrency in async/await and threading: https://blog.jetbrains.com/pycharm/2025/06/concurrency-in-async-await-and-threading/
PyDoll – Async Python scraping engine with native CAPTCHA bypass
Solved! 
This was a pretty "interesting" bug. Remember when I invented a way to implement #async / #await in #C, for jobs running on a threadpool. Back then I said it only works when completion of the task resumes execution on the *same* pool thread.
Trying to improve overall performance, I found the complex logic to identify the thread job to put on a pool thread a real deal-breaker. Just having one single MPMC queue with a single semaphore for all pool threads to wait on is a lot more efficient. But then, a job continued after an awaited task will resume on a "random" thread.
It theoretically works by making sure to restore the CORRECT context (the original one of the pool thread) every time after executing a job, whether partially (up to the next await) or completely.
Only it didn't, at least here on #FreeBSD, and I finally understood the reason for this was that I was using #TLS (thread-local storage) to find the context to restore.
Well, most architectures store a pointer to the current thread metadata in a register. #POSIX user #context #switching saves and restores registers. I found a source claiming that the #Linux (#glibc) implementation explicitly does NOT include the register holding a thread pointer. Obviously, #FreeBSD's implementation DOES include it. POSIX doesn't have to say anything about that.
In short, avoiding TLS accesses when running with a custom context solved the crash. 