Skip to content
This repository was archived by the owner on Aug 21, 2025. It is now read-only.

Conversation

@ngoldbaum
Copy link

Also splits out CT_LAZY_FIELD_LIST into a new listing of mutable flags, marking the old value as unused.

c.f. #2 (comment).

The next cleanup after this is to do the same thing for CT_CUSTOM_FIELD_POS and CT_WITH_PACKED_CHANGE.

@ngoldbaum
Copy link
Author

Looks like I need to test on Linux....

@ngoldbaum ngoldbaum mentioned this pull request May 28, 2025
6 tasks
@ngoldbaum ngoldbaum requested a review from colesbury May 28, 2025 20:53
Copy link
Collaborator

@colesbury colesbury left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll want to eventually use atomics to access ct_flags_mut, but that can happen in a later PR

Comment on lines 387 to 388
int is_opaque = (s->flags & _CFFI_F_OPAQUE);
flags |= is_opaque ? CT_IS_OPAQUE : 0;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where is this from? It doesn't look to me like it has any effect as new_struct_or_union_type below always sets CT_IS_OPAQUE:

https://github.com/Quansight-Labs/cffi/blob/1101273ac870779440793042c98511c9c5ff4b5a/src/c/_cffi_backend.c#L5134

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed the line you linked to in this PR to unconditionally set CT_UNDER_CONSTRUCTION. Let me see if I make the change you suggested in your other comment if I can get rid of this.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is done now.

Comment on lines 403 to 406
ct->ct_flags &= ~CT_IS_OPAQUE;
ct->ct_length = s->alignment; /* may be -1 */
ct->ct_flags_mut |= CT_LAZY_FIELD_LIST;
ct->ct_flags_mut &= ~CT_UNDER_CONSTRUCTION;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should remain as it was before:

  1. We should do ct->ct_flags &= ~CT_IS_OPAQUE because new_struct_or_union_type unconditionally set CT_IS_OPAQUE and this isn't an opaque struct ( because of !(s->flags & _CFFI_F_OPAQUE))

  2. No need to do ct->ct_flags_mut &= ~CT_UNDER_CONSTRUCTION because ct_flags_mut was initialized to zero.

Even though we want ct_flags to be immutable, it's okay to clear CT_IS_OPAQUE here because we are effectively doing it as part of the struct construction; the construction is just kind of awkwardly split between new_struct_or_union_type and this function.

Comment on lines +633 to +634
return ((ct->ct_flags & CT_IS_OPAQUE) ||
(ct->ct_flags_mut & CT_UNDER_CONSTRUCTION));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little skeptical of this: it feels like we haven't fully disentangled CT_UNDER_CONSTRUCTION from CT_IS_OPAQUE, but I think it's fine for now.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should entangle them fully, otherwise it will be hard to make it thread safe

@ngoldbaum ngoldbaum force-pushed the mutable-constructed-flag branch from ab9b3df to 1d70aa7 Compare May 29, 2025 02:01
@ngoldbaum
Copy link
Author

ngoldbaum commented May 29, 2025

I'd like to work on moving the other two mutable flags to flags_mut which will conflict with this PR. Let's bring this in and we can iterate on the UNDER_CONSTRUCTION flag - I think @kumaraditya303 wanted to make it e.g. a uint8 attribute of the CTypeDescrObject struct that gets saved and loaded with atomics. I'll also see if I can make a reasonable change that avoids needing to check both UNDER_CONSTRUCTION and IS_OPAQUE in is_hidden.

@ngoldbaum ngoldbaum merged commit b26c421 into Quansight-Labs:main May 29, 2025
54 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants