Re: Thread safe event loop
On Mar 24, 1:51 am, jonat...@sliid.org wrote:
Sam,
I can go the POSIX route, and probably will. I guess I was
mostly thinking: pthreads implements a mutex, so how do _they_
do it? If I could just do that myself then why not? If only
for the learning experience.
For starters, the implementation probably uses priviledged
instructions, which you can't use outside of kernel mode. (The
usual implementation will do a quick test and set outside of
kernel mode, but if that fails---there is contention---then it
will drop into kernel mode for the more complicated handling
necessary to suspend the thread.)
Marcel,
It's true that the portability issue is moot because I'm using
threads in the first place. My thought was that I could design
the threads themselves to be "unaware" that they were threads.
For example, if the Qt libs are unavailable my player drops to
the command line and just starts playing song after song in
one thread. No UI per se; just a radio. So I can write
everything in a "standard" way, and all that naughty thread
stuff will go in a source file with the UI, which will not be
especially portable anyway.
I'm not too sure how this would work under Windows, but the
classical Unix solution would be to use two processes (not
threads) for this. The basic player only supports command line
input, probably polling (e.g. function select or poll under
Unix, with a timeout of 0). The GUI is a separate process,
which starts the basic player, using a pipe to communicate with
it.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34