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

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