Top Level TWI's again was Re: [Haskell] Re: Parameterized Show
ahey at iee.org
Wed Nov 24 03:29:29 EST 2004
On Tuesday 23 Nov 2004 9:29 am, Keean Schupke wrote:
> Is this a joke?
> Seriously if you writing the OS in haskell this is trivial,
> you fork a thread using forkIO at system boot to maintain the driver,
> all 'processes' communicate to the thread using channels, the thread
> maintains local state (an IORef, or just a peramiter used recursively)
> myDriver :: (Chan in,Chan out) -> State -> IO State
> myDriver (in,out) state = do
> -- read commands from in
> -- process commands
> -- reply on out
> myDriver (in,out) new_state
How does this solve the problem we're talking about (namely preventing
the accidental creation of multiple processes all of which believe they
are "the" device driver for a particular unique resource)?
I take it we can't expose myDriver to the world at large, so what the
world at large sees must be just the unique channels to communicate
with one myDriver (which is forked only once somewhere outside main).
I can think of three ways of allowing the world at large to see the
1- Have them as top level TWI's. I guess you're not in favour of that.
2- Have getChannels :: IO (Chan in,Chan out) instead. But this buys you
no extra safety, and there's still the problem of how to implement
getChannels if we're not allowed top level TWI's.
3- Have the in and out channels of this and every other periheral passed
as an explicit argument to the user main. Yuk!, highly unmodular IMO,
not mention having the type of main depend on what devices were available.
Again it would seem an appropriate implementation of getChannels would
be a top level ..
getChannels <- oneShot $ do inChan <- newChan
outChan <- newChan
forkIO $ myDriver (inChan,outChan) state0
But of course this is so evil it's not worth further consideration :-)
More information about the Haskell