Bradley Dice

Can we revive this PR? Are there blockers?

@harrism I agree that there are varying degrees of scope that this could take. Let's limit the scope in this PR and restructure parts of `dependencies.yaml` but leave the rest...

Closing as stale. I do not plan to refactor the packages as described above in the near term.

Thanks @he-sk! This is really helpful. I won't be able to look at this for a little while, but I'll ask if someone else on the team has time.

@PointKernel Can you quantify the impact on binary size and compile time?

Vyas's answer covers everything I would say here. I'm going to leave this issue open for now. I want to cover this topic better in the docs.

@leofang I am looking a bit at fastrlock. I see we use its C API. Do you (or others) know if cupy require C API performance here? I began to...

Thanks @kmaehashi, that was my thought as well. I think updating fastrlock is probably the cleanest solution to ensure overhead is minimal. I have a draft locally that I think...

@kmaehashi I was curious how this effort was going. If `threading.RLock` is fast enough, we don't need to update `fastrlock` to support free-threading.

Oops. I didn't realize my approval would merge this PR. @rjzamora Can you apply my suggestions here? https://github.com/rapidsai/cudf/pull/16671#discussion_r1735013275 Also we need to make sure this information is all in sync...