Redesign interface between threads

[mateoconlechuga]

This needs to be overhauled, it has gotten bloated and unmanageable. Also fix scheduling while you're at it.

[adriweb]

std::condition_variable will have to be your friend :)

• http://en.cppreference.com/w/cpp/thread/condition_variable
• https://stackoverflow.com/a/16350623/378298

[mateoconlechuga]

Actually, I think the current system would work quite fine if variables were not crossing threads like they are now. The main emu QThread could simply pause the thread when debugging and whatnot.

[mateoconlechuga]

Pretty much fixed with 6ae5d1c. Just needs testing I guess, and then this can be closed.

[adriweb]

Well well well, seems to work fine on Desktop :)

But it completely broke emscripten: :P

• It'd be nice not to have debug.c become debug.cpp just because of a condition variable a mutex. These are available in pure C as well (C11 that is).
• Even when disabling debugging things, it appears to do "nothing", i.e. blank LCD. And I'm not sure what's happening since cpu_execute() seems to be running. Any idea?

[mateoconlechuga]

C11 stuff isn't available to me and I'm not sure why...

As for the blank LCD, I don't know how it is being updated :P Is there a way I can test emscripten?

[adriweb]

Aww, it appears not many stdlibs ship with C11 threads, so hum, I'll see if I can just use some preprocessor #ifs to just "comment out" the thread stuff for emscripten (since it's single-threaded there anyway). Unless we could just use pthreads, which is no issue on linux/mac, and on windows it's possible the winpthreads library is already used by the rest (?)
As for the blank LCD, I'm pretty sure the LCD itself isn't the issue, more like a symptom. (FWIW, I'm just calling lcd_drawframe(buf_lcd_js, &lcd); from time to time (when the JS requests it)).

Regarding testing emscripten yourself, hm, I can put some new version on the PB when the page is loaded with a special parameter or something... I'll let you know (but there isn't much to see :P)

[adriweb]

So with a newer OS/ROM I had, it seems to be getting further, just excruciatingly slow :P
I'll keep poking around...

[adriweb]

"solved" with 886b83c.

[mateoconlechuga]

I wouldn't consider it solved... what should be done to actually fix it? This could easily break again.

[adriweb]

Well, unless we can figure out exactly the required alignment "padding" at compile time, I guess we'll have to remove the structs packing, as per @jacobly's suggestion.

[jacobly0]

That's what aligned attributes are for. ;)

[adriweb]

Hmm right, we should try that first :D