Open ZorroMundo opened 6 months ago
Are there precedents in other programming languages or engines? The proposal feels pretty dry, and I am not sure what I should be in favour of.
I second this question, with the specification of script languages and similar cases, as opposed to low level languages like c++, does Lua, Python, etc. have this?
I second this question, with the specification of script languages and similar cases, as opposed to low level languages like c++, does Lua, Python, etc. have this?
The thing is, other scripting languages don't require such low level threading as GDScript does.
The thing is, other scripting languages don't require such low level threading as GDScript does.
Do they not? And does GDScript really require low level threading support? I'd say python is far more likely to need it as a general purpose language than a script language for games
And I'm not even sure the language can support all of that directly without other low-level changes to the script because of how statements are processed and broken down, the handling of calls and data exchange etc., it might not be as simple as adding new types (which isn't simple in itself)
The thing is, other scripting languages don't require such low level threading as GDScript does.
Do they not? And does GDScript really require low level threading support? I'd say python is far more likely to need it as a general purpose language than a script language for games
And I'm not even sure the language can support all of that directly without other low-level changes to the script because of how statements are processed and broken down, the handling of calls and data exchange etc., it might not be as simple as adding new types (which isn't simple in itself)
No, I mean, godot forces you to use low level threading, with simple constructs such a mutexes and you having to deal with synchronization manually because we have no multi threaded containers.
It doesn't force you to do that, and again do other script languages and related ones have lock-free or thread safe containers?
For modifying containers you should be using mutexes etc. anyway they won't be thread safe I'd say, I don't see how that has anything to do with atomics
Describe the project you are working on
I'm working on a file reader (with a custom formats)
Describe the problem or limitation you are having in your project
While using threading, I have a variable that's an int, and it's supposed to update once one entry finishes reading, since the threads are started from another thread (that waits the child threads to finish), the variable won't sync with the other threads when the thread changes it's value
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Atomic variables will allow the other threads to be able to update this number (and having it being shared)
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
If this enhancement will not be used often, can it be worked around with a few lines of script?
It could be worked around with Arrays, though it makes the code a little less readable
Is there a reason why this should be core and not an add-on in the asset library?
It could be useful for managing shared variables that don't use pointers