Closed ncharl closed 1 year ago
The alternative is to do this all with forks and interprocess communication (via pipes?)
Any preference, @michaelcadilhac ?
So far, I've used forks, not threads, so this is not a problem. If threads are desired for some reason, static
can be changed for thread_local
(https://en.cppreference.com/w/cpp/language/storage_duration).
Ah yes good ol' pthread local! I think because of the need to return nontrivial structures to the caller, threads might be easier to use in this case.
Op di 2 mei 2023 16:18 schreef Michaël Cadilhac @.***>:
So far, I've used forks, not threads, so this is not a problem. If threads are desired for some reason, static can be changed for thread_local ( https://en.cppreference.com/w/cpp/language/storage_duration).
— Reply to this email directly, view it on GitHub https://github.com/gaperez64/acacia-bonsai/issues/25#issuecomment-1531564876, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAUJJ2INZWFHN4CTKVPHKLDXEEJSHANCNFSM6AAAAAAXS3JCME . You are receiving this because you were mentioned.Message ID: @.***>
There's two global variables in
vectors.hh
that have to do with the number of (non)boolean states in the current automaton. These variables have to be set correctly for everything to work, but as they are global variables, this complicates using multiple threads as they'd share the variables. Would there be a convenient way of making these not global? @gaperez64 suggested moving either these variables or a pointer to a thread-specific Configuration struct containing the variables into each instance of a vector.