I thought you might want to see Einar's reply
------- Forwarded Message
Date: Fri, 26 Sep 1997 11:32:15 +0200
From: Einar Wolfgang Karlsen <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject: Re: A Users Plea for Daemon Threads
Simon writes:
> An alternative:
>
> forkIO :: IO () -> IO ThreadId
>
> signalThread :: ThreadId -> IO ()
>
> signalThread makes the current IO action of the thread return immediately wit
h
> an IO error of some kind (which it can catch; for example it might want to ki
ll
> its children before dying).
Killing threads is a feature that I would support in any case.
> Einar: how bad would it be to have to kill daemons explicitly?
Actually, this is what we are doing now, but indirectly. We maintain,
for each encapsulated tool, an IO command to shut down the tool. This
set of termination commands are invoked whenever the application calls
endSession. However, rather than letting the termination command be
signalThread tid
it is for the time being a command that sends a termination message
over the pipe on which the thread is waiting for input. The thread will
read this message and terminate itself. With thread identities, the
implementation would be nicer (and more general), but the application
would maintain the structure that it has now.
Even with thread identities, tools must register themselves with some
"session manager" that maintains the set of termination commands. And
again - the application must explicitly invoke the command endSession.
Generally I would like to avoid this and rely on an active garbage
collection scheme solely. I think that daemon threads provide a general
solution for doing so. The question to me is if there are better
solutions.
Einar
------- End of Forwarded Message
