cc@tomasr8

The context here is in theset implementation, we have a number of functions that take a possiblyNULLiterable argument:

We generally want to lock theiterable if it's not NULL. There's enough uses that I think it's worth handling inpycore_critical_section.h rather than insetobject.c.

Related PR:#113800

The context here is in theset implementation, we have a number of functions that take a possiblyNULLiterable argument:

cpython/Objects/setobject.c

Lines 1015 to 1016 in514b1c9

	staticPyObject*
	make_new_set_basetype(PyTypeObject*type,PyObject*iterable)

I kind of wonder if we do really want to lock all of the iterables... Ultimately the dict case could proceed lock-free and for some arbitrary object that isn't a dict or a list we don't really need to lock it (e.g. for a Python used defined type it's presumably protected by some other Python lock if it needs to be thread safe).

But I could see this as being generally useful too.

I kind of wonder if we do really want to lock all of the iterables...

Yeah, I think we will want to refine the locking approach in the future, but locking all the iterables works for now. I think we want to actually lock in thedict case so that the whole operation appears atomic, even though the iteration over the dict is thread-safe without a lock. IIRC, we have code that assumes thatset(dict) is atomic.