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
