On Fri, Jul 10, 2026 at 12:32 AM David Nicol <[email protected]> wrote:
> > On Fri, Jul 10, 2026 at 1:06 AM C.J. Collier <[email protected]> wrote: > >> >> It would give modern cloud-native drivers a standard interface to target, >> rather than everyone hacking their own custom event loops into individual >> DBDs. >> >> Thoughts? >> > > > Nice! The problem with event loops is that a system should have only one. > Is there a thing like "async-check-and-do" that will do stuff or not block, > that could get polled as part of an existing event loop? > > A quick search yields https://metacpan.org/dist/POE-Component-EasyDBI for > discussion; POE wants to be the standard event loop services provider. > > I'm old-school and still write loops around select(2), which allows async > comms with separate processes using a little language over a pipe, > robustly, but that's no way to define a standard interface unless the > facility gets wrapped somehow. The tradeoff of only polling after the > select times out would be acceptable, I think, although it wouldn't be as > responsive as including the protobuf system's file descriptors in the > select set. > > I don't know if there is a standard for mapping a FD number to a > [on-readable, on-writable, on-error] coderef triple, aside from just doing > that with an AoA, but were I wanting to integrate an async system into an > existing select loop, I could work with that. Especially if the system > offered to take the same shape of data as an input for its own select > loop.POE might have a standard for such things, I don't know. > > cheers > > dln > > > -- > "The profit motive is often in conflict with the aims of art." -- Ursula > K. Le Guin > David, thank you for reinforcing the importance of the single event loop. That’s a fundamental constraint any enhancement to DBI must honor. Your insights, combined with the trend towards streaming protocols and managed services in cloud databases (e.g., gRPC for BigQuery/Spanner, and the native protocol for Cloud SQL for PostgreSQL <https://cloud.google.com/sql/docs/postgres>), highlight the value of standardized non-blocking operations within the DBI ecosystem. I’m mindful of the potential complexity and maintenance burden of introducing new concepts into the DBI core. However, the complexity seems to be arising anyway, but in driver-specific ways (e.g., DBD::Pg’s async features). Without a common interface, we risk greater ecosystem fragmentation. Centralizing the async interaction model within DBI, while keeping it optional, could *tame* this complexity. Furthermore, DBI has a history of adapting beyond traditional SQL databases, as seen with drivers like DBD::CSV. A well-designed, event-loop-agnostic async interface could not only benefit SQL databases but also pave the way for more performant and idiomatic drivers for other modern data systems, including NoSQL stores, message queues, and real-time platforms, which often rely on persistent connections and server-push. To what extent would the community be interested in formalizing an exploration of this? I propose we establish a small working group to design an optional, additive interface to the DBI specification. The goal would be to offer a clear, event-loop-agnostic contract for drivers to integrate with any external event loop. This would not alter behavior for existing synchronous code but would aim to provide a solid foundation for the next generation of Perl database and data source drivers. Is this a direction others would be keen to contribute to? Regards, C.J.
