Re: [AD] OSX END_OF_MAIN musings

[Elias Pschernig <elias@xxxxxxxxxx>]

On Fri, 2004-12-03 at 23:44 -0800, Chris wrote:
> I've just been thinking. The reason we haven't been able to get rid of 
> END_OF_MAIN on OSX is because the input thread needs to be the main 
> thread, and we'd run the main program from a secondary thread, right? 
> END_OF_MAIN constructs the real main function, starts a second thread 
> with _mangled_main, and leaves the main thread to grab input and stuff. 
> Basically swapping the timer and main threads compared to other OS's.

That's what I understood. And since _mangled_main calls allegro_init and
so on, there's no way the real main in Allegro already could run it as a
separate thread.

> How efficient would it be to use fork() in this case? If install_allegro 
> calls fork, it can let the child process continue on as normal, and 
> leave the parent process forever stuck in install_allegro, acting as the 
> polling thread.
> 
> I'm not too sure how feasible this is though. I can see concerns about 
> the program's resources being doubled, but perhaps there's a way around 
> that? Or maybe it's not that much of a problem?
> 

If that is a concern, could just use clone instead, and makes it share
all resources with the parent.

So, just thinking aloud so I understand this:

main() // in user code
.
.
.
install_allegro()   //call fork/clone
.                   .
.                   .
.                   .
thread 1            thread2
never returns       returns to user's main
start event         .
handling loop       . 
.                   .

Heh, nice. It seems to solve the problem. The only difference is,
pthread_create always continues with a specific function, while with
fork/clone, you can decide which thread start the event handling.

Now, the question is, how much does OSX like fork/clone? Maybe they are
linux only? Or at least, don't work as expected.

-- 
Elias Pschernig