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

[Chris P. <sf...@ma...>]

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?

> 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