Re: [AD] OS X full screen resize (was Re: Allegro 5 TODOs (from wiki))

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On 12-Dec-08, at 5:00 PM, Peter Hull wrote:
> I found that some parts of the window creation process _had_ to be
> done on the main thread, so given that it had to be done sometimes, it
> seemed a neat way do synchronisation by serialising everything to the
> main thread.

Sure.

> However Allegro has turned out 'more multithreaded' than
> I thought it would be, so some mutexes will need to go back in (one
> thread iterating through displays while another thread is
> creating/destroying them is a good example)

We should probably go through the code very carefully to try and catch  
things like that - or, even better, try to make it break explicitly  
with a test program.

Which brings us back to something like A4's test program. Would it be  
worthwhile to "simply" port that to A5? "Simply" because there's of  
course nothing simple about it without having access to a GUI/menu.

> IIRC from Apple's docs*, one thread per GL context should be perfectly
> OK, but if you have >1 thread on the same context you need to do your
> own locking. However it seems to suggest that the problems are just
> visual, not crashes. I haven't checked but if you're saying that 2
> threads can't draw to 2 separate ALLEGRO_DISPLAYS then we must have
> made a mistake somewhere in the code.

Hmm... well, it's probably fine if the thread creates its own display.
While playing around with this and looking at the examples, I came  
across the following note in ex_threads2 (which has multiple threads  
drawing stuff at the same time):

/* Note:
 * Right now, A5 video displays can only be accessed from the thread  
which
 * created them (at lesat for OpenGL). To lift this restriction, we  
could
 * keep track of the current OpenGL context for each thread and make  
all
 * functions accessing the display check for it.. not sure it's worth  
the
 * additional complexity though.
 */

Just for information's sake: does Allegro offer a way (in the public  
API) to get and set the current context? If it doesn't and we do want  
it, then it has to be "neutral" enough in the sense that the same code  
should work with (say) D3D.
Personally, I think that's opening a whole new can of worms and I'm  
not sure we want to go there. Having every function check the context  
before accessing the display sounds a bit messy, as though we're doing  
something that we really should not be doing. I think the restriction  
is fine, but it needs to be clearly documented.
On the other hand, I can see a situation where it would be useful to  
spawn a dedicated thread that will manage the drawing operations...

So, not sure what to do here, but it doesn't seem to be simply an OS X  
issue.

> * I remember reading something that wasn't quite this:
> http://developer.apple.com/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_threading/chapter_12_section_1.html#/ 
> /apple_ref/doc/uid/TP40001987-CH409-SW1

It's not stated very explicitly, but:

"Use only one thread per context. OpenGL commands for a specific  
context are not reentrant. You should never have more than one thread  
accessing a single context simultaneously.

If for some reason you decide to set more than one thread to target  
the same context, then you must synchronize threads by placing a mutex  
around all OpenGL calls to the context, such as gl* and CGL*"

and (under "When Things Go Wrong"):

"If you don't set up threading correctly, you'll most likely see your  
application freeze or crash. Things typically go wrong when your  
application introduces a command to the graphics processor that  
violates threading practices. The bad command will cause the processor  
to hang. The CPU blocks against that, causing any drawing onscreen to  
stop and the spinning wait cursor to appear."

In this particular case of the fullscreen crashes, I don't think the  
problem was due to multiple threads trying to perform drawing  
operations at the same time, but rather the thread that was doing the  
drawing not being the same one that created the context in the first  
place.

Evert