Frequently, when developing reactive systems using Concurrent Haskell,
threads are set up to provide some internal form of control for a
wrapped tool, i.e. threads that interact with an external GUI, DBMS or
some other tool of the environment. In many cases, these threads listen
to external events by waiting on a threadWaitRead. I will refer to such
internal threads of control as deamon threads (Java terminology).
PROBLEM:
========
The main process is kept "alive" (hanging around doing nothing sensible
would be a better phrase) even though the application proper has
terminated a long time ago. Rather we would like the main program to be
terminated.
The reason for this lack of termination is that there are still deamon
threads around waiting for input over a threadWaitRead (say).
AD HOC SOLUTION:
================
Provide some feature that explicitly terminates the session and shuts
down all deamon threads. Cumbersome solution, which does not quite fit
with the paradigm that the main program is terminated whenever there
are no more active threads around (there are pending threads, but they
are not useful/important).
BETTER SOLUTION:
================
Java has solved the problem by introducing deamon threads. A process is
then terminated when all all other non-deamon threads have terminated
or are blocked. A pending deamon thread is therefore not sufficent to
keep the main program alive.
PROPOSAL FOR CONCURRENT HASKELL
===============================
Deamon threads could be introduced in Haskell by providing a new
command
forkDeamon :: IO () -> IO ()
Such deamon threads would behave just as any other thread, apart from
the fact, that they will be garbage collected when there are no proper
non-deamon thread around.
Deamon threads could probably be introduced by adding another bit to
the internal thread state. The termination condition (that eventually
leads to printing "No runnable threads!") should then be changed so
that pending deamon threads are not sufficent to keep the main program
running.
Conceptually it is a small change to Concurrent Haskell which would
take the advantage of the active garbage collection scheme one step
further. Our applications could benefit significantly from such a
feature, since we would no longer have to care about explicitly about
closing the session and shutting down wrapped tools. This would
automatically appear when the last application/working thread gives up
air (the "management would then pack up and go home").
Einar
