Re: [PATCH 00/24] C++ification of struct so_list

Simon Marchi
2023-10-17T19:53:43Z

On 10/17/23 15:20, Pedro Alves wrote:
> On 2023-10-10 21:39, Simon Marchi wrote:
>> This series modernizes the struct so_list area by C++ifying it a little
>> bit and replacing the manual linked list implementation with
>> intrusive_list. It also contains a few other cleanups written along the
>> way.
>
> Very nicely split. Thanks. I sent a few comments, but nothing too serious.
> The only thing on my end that requires some churn is the pointer vs reference
> thing in the disposer. Otherwise, all LGTM.

I dropped the "use reference in disposer" patch.

> Oh, I did notice that "struct so" ends up as an ungreppable/unsearchable
> name, and wondered whether that is going to make our lives harder in practice.
> Maybe we should consider renaming it to "shared_obj" or "shobj" or something easier
> to grep. Or maybe it doesn't matter. But no real strong opinion, I think I'm OK
> with "so" too.

I wondered about that too. If we are going to change the name, perhaps
we can find a more accurate one. I'm currently working on trying to
make it possible for program spaces to have more than one solib
implementation providing so_lists / sos. In the context of ROCm, this
will allow solib-svr4 to provide sos for the host, and solib-rocm to
provide sos for the GPU. I will also try to see if the JIT mechanism
can then be changed to be one more solib provider, see if that
simplifies some things. In the case of ROCm, we don't talk about shared
objects, but code objects that are loaded in the memory space. In the
case of JIT... not sure what we call the generated code, but it's not
really a "shared object". Perhaps there is a generic name we can find
for those pieces of code that can be loaded and unloaded at runtime.

In the mean time, I'll go with "so", since it just seems weird to have
intrusive_list<so_list>. If we want to change it again it's not really
complicated, there aren't that many instances.

Simon