Re: Re: [RFC] [Discussion] Persistent CurlShareHandle objects

On Thu, Oct 24, 2024, at 13:01, Christoph M. Becker wrote: > On 23.10.2024 at 21:42, Rob Landers wrote: > > > On Wed, Oct 23, 2024, at 21:20, Eric Norris wrote: > > > >> Were you also suggesting that I shouldn't ask a question about the > >> implementation regarding using EG(persistent_list) vs. a module > >> global? I'm torn; I agree that it is an implementation detail but I > >> was hoping to actually get wider input since it generated discussion > >> in my pull request. Since no one responded here I felt like it'd be a > >> lightweight way to get feedback on what people felt, but the lack of > >> response probably means that people don't feel strongly enough about > >> it. > >> > >> That said, after reflecting I think I would agree that it is > >> unnecessary to add this as a question, and I'll continue with the > >> implementation as-is in the PR. If people would like to send feedback > >> on using EG(persistent_list) instead, feel free to do so here or in > >> the PR. > > > > For what it is worth, I think you should go for the EG(persistent_list) method. Over on > > FrankenPHP, we are looking into some improvements to TSRM (so that Go and PHP can share some of the > > same locks, among other things) and EG uses TSRM while I think a module global would not. > > For practical purposes, EG(persistent_list) is a module global > (can > bikeshed whether the engine is a module). In particular, both use TLS > for ZTS builds, and neither can access entries of other processes and > threads, respectively. > > I still think we should not add new stuff to > EG(persistent_list); > after all, resources are scheduled for removal, and likely > EG(persistent_list) will finally be removed, too, and then we > would > need to convert to a curl module global anyway. > > Christoph > > Sounds like a perfectly good reason to not use EG(persistent_list) to me.. — Rob