WIP - Working on new thread TODO items #119
Conversation
|
I never looked into what lua_newthread does in detail but wouldn't this
imply that all changes we make to our state object need to be under a mutex
(with all the performance consequences that entails)?
Il lun 11 nov 2024, 11:09 MrNavaStar ***@***.***> ha scritto:
… I hope I'm on the right track with these TODO items, the main reason I am
working on this is because I need new thread to keep its context (should
have just added context in the other pr, oh well). Figured I would try and
take a crack at completing the other items of it while I'm here.
I'm not sure how to handle the go registry list. do we need to deep copy
all the items in the list? or is a reference ok? Idk, lmk what your
thoughts/plan for this is.
------------------------------
You can view, comment on, or merge this pull request online at:
#119
Commit Summary
- eed5441
<eed5441>
work on new thread TODO items
File Changes
(1 file <https://github.com/aarzilli/golua/pull/119/files>)
- *M* lua/lua.go
<https://github.com/aarzilli/golua/pull/119/files#diff-3768a1120a2b466b1753b0c72532dceea154a23598fd63e8489118130803fcd9>
(9)
Patch Links:
- https://github.com/aarzilli/golua/pull/119.patch
- https://github.com/aarzilli/golua/pull/119.diff
—
Reply to this email directly, view it on GitHub
<#119>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACKEBCFYKRNFCUPGWBR4AD2AB65DAVCNFSM6AAAAABRRPM2B6VHI2DSMVQWIX3LMV43ASLTON2WKOZSGY2DQOBSHA4DEOA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
From what I gather, This stack overflow post has some good information: https://stackoverflow.com/questions/26574705/lua-newstate-vs-lua-newthread however, if we decide to keep the same registry list (and maybe free indices list?) without copying, we probably need a mutex for that |
|
The lua documentation says this:
|
|
Right, so it's a new state object entirely with its own stack. Shouldn't require a mutex right? There is also the Lua lock and unlock functions to be implemented that handle the mutex for the shared environment |
|
Suppose something new is registered in a thread and placed in a global variable, does it become available to other threads? |
|
I believe it does, however that is handled by the lua runtime (assuming we implement the lock and unlock functions if they haven't been already). We shouldn't need our own mutex for that |
|
If that is the case the registry needs to be shared between the threads and probably also need synchronization. |
|
Okay cool, that was the main thing I was unsure about. I'll take a crack at that tomorrow. Does the free indices list need to be treated the same way, or is a copy okay? |
|
Threading mostly works, however past creating 40+ threads things start to fall apart. I suspect I am hitting some sort of stack limit. This isn't really an issue for me, but perhaps its still something we want to look into? lmk if there is anything else concerning you see or something you don't like the implementation of. I also noticed that the |
What does falling apart means? |
|
It crashes - the errors mention gc issues. I can't make much sense of it |
|
Sounds like memory corruption, tbh. |
|
What would cause that? Some buffer overflowing or something similar? |
|
Having trouble debugging something else. Very rarely, I get this: The error is coming from the L.Call() inside the goroutine in the threads.go example. I've been unable to track down where its coming from inside it. Any thoughts? |
2 participants
I hope I'm on the right track with these TODO items, the main reason I am working on this is because I need new thread to keep its context (should have just added context in the other pr, oh well). Figured I would try and take a crack at completing the other items of it while I'm here.
I'm not sure how to handle the go registry list. do we need to deep copy all the items in the list? or is a reference ok? Idk, lmk what your thoughts/plan for this is.