| [AD] OSX END_OF_MAIN musings |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: alleg-developers@xxxxxxxxxx
- Subject: [AD] OSX END_OF_MAIN musings
- From: Chris <chris.kcat@xxxxxxxxxx>
- Date: Fri, 03 Dec 2004 23:44:43 -0800
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:return-path:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:x-enigmail-version:x-enigmail-supports:content-type:content-transfer-encoding; b=GSL54TQCYqwO70aIfd5iv4MCT2+xukAv3DghvwAMaLmhsgdIkJ9p9QT/W8XHM/uN9k30Xw+LnBhajurTSzTheBOYnHzXGsDDTo2BuCKDIxyytvuGkMgiPmpKxPwPqqm98/RuUpxH6ijpP57LB6q0AqVDSy5MbOFjO+zGjNNN8BQ=
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.
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?
Any thoughts/ideas?