Mark Duckworth wrote:
On 12/22/10 6:23 PM, Henk Robbers wrote:To be fair this is to suggest GEM supports full multithreaded operation, including multiple threads interacting with user interface elements? Even windows doesn't support that, all UI code has to be in the main thread. Kind of reaching for a feature nobody needs?A program that does not need rentrancy because it doesnt use threads should be most comfortable with a few bindings using a static array. So dont worry. Let people writing multithreaded applications find the solution they need. OTH, I like the idee of XaAES setting up a userdef stack per application. Shouldnt be too difficult. The AES already needs application specific data. I wrote AHCM for that purpose, when XaAES itself was a usermode program. Switching to user mode looks like a good idee for the KM.
You are overstressing a little bit. XaAES lives in a multitasking environment. Technically, all GEM applications are threads of the AES. Together with the AES all non GEM applications are threads of MiNT. Because MiNT does not provide overlapping address spaces. (As yet). -- Groeten; Regards. Henk Robbers. http://members.chello.nl/h.robbers Interactive disassembler: TT-Digger; http://digger.atari.org A Home Cooked C compiler: AHCC; http://ahcc.atari.org