Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added user-defined context variable guard #800

Open
wants to merge 1 commit into
base: v3.8.x
Choose a base branch
from

Conversation

BrodyHiggerson
Copy link

Fitting with the "don't pay for what you don't use" concept, I wanted to have an optional way of injecting some kind of lock/guard around context variables in the registry.

I let the user define how the lock is created since, for me, I use a fiber mutex rather than std::mutex, so I need to be able to define it myself. I'm using the lock in the 'leaf nodes' of the function calls since I can't support recursive mutexes and the end result is the same.

Addresses #799

(Let me know if you want a PR against another branch; maybe main?)

@skypjack skypjack self-assigned this Nov 20, 2021
@skypjack skypjack added the triage pending issue, PR or whatever label Nov 20, 2021
@skypjack
Copy link
Owner

Unfortunately, this PR is no longer valid (if we consider branch wip as it ought to be, that is about to be merged with master).
Briefly, I've introduced a registry_context object here to address #575 (that makes perfectly sense to me). All functions from the registry have been moved to this object. These are the only functions available in the registry now.

I've no problem merging or reproducing the intent of this PR on a branch, adapting it and then porting it to master. There is no need for you to intervene. However, I wanted to ask you what your plans are to avoid conflicts. 🙂

@skypjack
Copy link
Owner

Actually, another option could be to turn the context type in a template parameter.
This way users can inject their own guarded maps or whatever or even suppress it. 🤔

@BrodyHiggerson
Copy link
Author

BrodyHiggerson commented Jan 31, 2022

@skypjack I actually had to comment out the

#ifndef ENTT_REGISTRY_CONTEXT_GUARD
	#define ENTT_REGISTRY_CONTEXT_GUARD()
#endif

section as include ordering was messing with it - some files/libraries would get to config via various utilities and I was struggling to always keep my own header/define before it. I think there's probably a better solution on the cards, but I'd definitely like some way to inject a custom lock either way. A template param could be nice - means the user can typedef entt::registry and use it in their code without worrying about include order shenanigans. I would just be worried about for example having that type replace the entire map and machinery and force the user to re-implement it - I want exactly what the context vars do, just with a lil' interception ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage pending issue, PR or whatever
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants