Re: [RFC] [Discussion] Persistent CurlShareHandle objects

On Mon, Nov 4, 2024 at 2:21 PM Jakub Zelenka <bukka@php.net> wrote: > Hi, > > On Wed, Oct 9, 2024 at 10:18 PM Eric Norris <eric.t.norris@gmail.com> > wrote: > >> Hello all, >> >> After receiving some feedback about >> https://github.com/php/php-src/pull/15603, I'm >> formally proposing an >> RFC to add persistent curl share handles here: >> https://wiki.php.net/rfc/curl_share_persistence >> >> > I think what's really needed for this is to have some infrastructure for > connection pooling. The current persistent connections in streams (which > includes mysqlnd, redis and its other users) are quite primitive and not > that well managed. This might occasionally result in incorrect clean up and > possibly having too many connections open. > > What I think we need is a new internal API that would be handled by SAPI. > So basically some generic API that SAPI would hook into and manage the > connections. For extension it could work by registering the pool with some > connect and clean up callbacks and various parameters (e.g. timeout and > maybe something else). Then it would be just getting the connections from > it. It should be quite generic so it can support also curl handles so the > actual connection should be opaque. The point here is that SAPI should > handle the pool and deal with timeouts / clean up. This could work pretty > well for the threaded SAPI's. FPM is a bit limited as it's per worker but > it could potentially set its own limits and could still better handle > timeouts and clean ups. > > I think there should be not such a big oppositions to the general concept > because this is already rooted in PHP in the form of persistent resources > and this just tries to implement the same for objects which we might > eventually need for streams if they ever get them converted to objects. > There are likely many application successfully using persistent resources > and it could be quite problematic to drop the whole concept. > > Basically what I want to say is that we have got chance to implement it > properly for objects and we should not end up with the same sort of way how > it's done currently for resources. The better way is to have SAPI managed > API IMHO. > > Just for the reference I voted yes on RFC because that's just about the concept and user API which I think is fine and it's inline with persistence that we already have. But note that it doesn't mean that we will accept implementation in the current form. Regards Jakub