Re: [Alephmodular-devel] Detangling/de-Mac-ifying

[Br'fin <br...@ma...>]

On May 18, 2005, at 2:11 AM, Chris Pickel wrote:

> On May 18, 2005, at 12:00 AM, Br'fin wrote:
>
>> Main Thread (Handles Mac Events) - Also handles updating the world  
>> and rendering the screen.
>> Input Thread (Runs as a VBL API thread) - Polls mouse location and  
>> keyboard state 30 times a second, updates input queues
>>
>
> Hmm, I think I see how this is supposed to work. I read through  
> what I could find of thread use, and I find one thing somewhat  
> curious: there doesn't seem to be any concept of thread-safety in  
> the code. mytm.h defines two mutex routines, but they aren't used.  
> It appears to me that the assumption in the code is that only the  
> input thread is responsible for write_index and its contents, while  
> only the main thread is responsible for read_index and its contents.
>
> This might be a good assumption, but I'm not convinced that it's  
> safe to do; the input_controller function does a comparison between  
> read_index and write_index, and I was always taught you're not  
> supposed to do that without a mutex.
>
> The other thing that I notice is that the thread routines are in  
> plain C that's not easily decipherable. Perhaps this should be  
> cleaned up and C++-ified?

Most likely most of the thread code dates back to the Classic MacOS  
API. I've no idea if the VBL interrupts for threading even had the  
concept of a mutex. Having a thread class of some ilk may very well  
be appropriate, especially as the existing ones rely on a couple  
different mechanisms.

>> The specific problem I ran into when doing mousing in AlephOne was  
>> that GetMouseLoc in OSX was not updated in the VBL thread. So at  
>> the very least I want one thread to handle Carbon Events while the  
>> thread that handles updating the world and rendering is dealt with  
>> separately so the Carbon Events can get processed in a timely  
>> fashion for capturing various Mouse Moved events.
>>
>
> It's not? From the looks of it, input_controller() (the thread  
> function) calls parse_keymap(), which calls mouse_idle(), which  
> calls get_mouse_location(). Isn't that where the call should be? Or  
> are you picturing an interrupt-based event system rather than a  
> polling loop?
>
> - Chris Pickel

With the current layout, the get_mouse_location isn't functioning  
right under OSX. You can try playing with it. But it didn't seem to  
be updated all the time in the way that the keyboard polling function  
was. Meanwhile the advised way of catching mouse movements under OSX  
is by catching the explicit Mouse Moved events via a Carbon Event  
Handler.

-Jeremy Parsons
http://alephmodular.sourceforge.net/