Top Level TWI's again was Re: [Haskell] Re: Parameterized Show
k.schupke at imperial.ac.uk
Wed Nov 24 06:50:17 EST 2004
There is no problem getting multiple copies of the channels... I take it
you are not familiar with the internals of OSs (I have written a small
OS myself, complete with real device drivers)... The OS is started at
boot, it initialises its own state, then it forks the device drivers, then
it forks user processes (simplified but adequate).
Lets design a small Haskell OS, the OS has the handles for the device
The program MUST be passed the channels to the OS (there is no other way)...
These channels allow other channels to be opened, they would be like the
main :: Chan CMD -> Chan RSP -> IO ()
main cmd rsp = do
writeChan cmd (OpenDevice "devname")
h <- readChan rsp
case h of
(OpenOK in out) -> do
writeCan out (DeviceWriteString "hello")
status <- readChan in
_ -> error "could not open device"
Here you can see that we could try and open the device again, however the
OS would either multiplex or serialize the device depending on type.
Adrian Hey wrote:
>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
> return (inChan,outChan)
>But of course this is so evil it's not worth further consideration :-)
>Haskell mailing list
>Haskell at haskell.org
More information about the Haskell