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

Console class allocation #11

Open
s-daveb opened this issue May 4, 2015 · 0 comments
Open

Console class allocation #11

s-daveb opened this issue May 4, 2015 · 0 comments

Comments

@s-daveb
Copy link
Collaborator

s-daveb commented May 4, 2015

As mentioned in commit f059129 (Make memory/cpu static members of console), we should figure out the proper way to share components of the emulator between the different components that interact.

Coming from a C++/C# background, we are familiar with singletons/static classes (respectively), but from what i was reading here, in D, local and static variables exist on a per-thread basis. This means if we simply create a static class, each thread will have a copy of the Console object, and a separate CPU/Memory object, since those are allocated in the console.

We have two options, and I want to hear your opinions, @bobomb:

  1. Use the singleton pattern, alá C++ (private ctor, private shared instanceRef, public static getReference() method, manual thread locking for each object)
  2. Use a shared static class. This will be initialized before main() is even called. All Console members will need to be marked shared static, but this might handle any threading issues that might arise.

(I still believe we should implement the different processors of the NES in different threads; even though we could just time-slice, I feel this will be more akin to how the real NES operated, and we can let each thread implement its own timing)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants