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 driver.
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
master device.
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.
Keean.
Adrian Hey wrote:
On Tuesday 23 Nov 2004 9:29 am, Keean Schupke wrote:
Is this a joke?
No.
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 channels.
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 :-)
Regards -- Adrian Hey
_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
_______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
