avoiding freezes with real concurrency

5.21: 6.2: adda/translate/co
there were 2 cases of multi-tasking:
# gui reactor:
. the multi-tasking done for gui response
could really be done by
frequent subroutine calls to the gui handler
instead of swapping threads with it;
because, its endless event loop is equivent to
an endless number of brief loop body calls .
# time-slicing:
. when a program is composed of threads (co.programs),
it expects them to be time-sliced,
so that, for instance,
if there are several things to animate,
each refresh of the screen is showing
what appears to be concurrent activity .
. unlike the gui-reactor case,
there is no way to use a subroutine call for
sharing cpu time with anonymous threads;
because, generally they cannot be decomposed into
an endless number of brief loop body calls .
. a similar case is anonymous co.programming,
where the user runs several programs at once;
this situation is significantly unlike
app-orchestrated co.programming because
user-launched co.programs aren't aware of each other;
so, even if c did support coroutines,
they would not be of use in time-slicing here .
5.22:
. another place where programs can hang
besides infinite looping and recursion,
is waiting for devices to respond;
the addx library designer needs to know
where these hangups are,
and not give tasks direct access to them .
. instead,
the sub is suspended until the wait is over;
and control is given instead to gui reactions .
[6.2:
. it may be the case that
only hardware-based concurrency could provide
the needed protection from device freezes;
that means the base language can't be just c,
but involve c+posix, obj-c + gcd, or qt .]

5.29: web.adda/translate/co/open concurrency api's:
. unix is a std open platform now,
isn't there some concurrency api defined in posix?
. an overview of user-level vs kernel-level
and threads vs processes:
. processes communicate via sockets
pos:
. addx's primary use for threads is that
the main thread is adde dishing up the gui,
and it sends messages to a side thread
for housing the apps that do the actual work .
. while getting bogged down in posix idioms
it occured to me that since my first target is mac,
I should follow what they suggest
in the way of concurrency primitives .
...
there's also qt:
both open, cross-platform and easier than posix .