Re: [Haskell-cafe] Re: ACIO versus Execution Contexts
On Tuesday 30 Nov 2004 3:02 pm, Lennart Augustsson wrote:
I reiterate: not even device drivers written in C use TWIs. (Well, at least not quality drivers. :))
A finite pool of N devices is still a unique resource. Ultimately you have to contain the problem locally with a modular solution, or all the unique state handle "buck passing" to higher levels (via who knows what intermediate modules) takes you all the way up to main. This is technically feasible, but highly un-modular and certainly not a desirable characteristic of any programming language (at least not one whose use I would advocate). Regards -- Adrian Hey
Adrian Hey wrote:
On Tuesday 30 Nov 2004 3:02 pm, Lennart Augustsson wrote:
I reiterate: not even device drivers written in C use TWIs. (Well, at least not quality drivers. :))
A finite pool of N devices is still a unique resource.
Ultimately you have to contain the problem locally with a modular solution, or all the unique state handle "buck passing" to higher levels (via who knows what intermediate modules) takes you all the way up to main.
This is technically feasible, but highly un-modular and certainly not a desirable characteristic of any programming language (at least not one whose use I would advocate).
It's not a language issue. It's a design issue. And in the case of device drivers you do want to pass the buck up to the layer that handles device drivers. Having each driver keep it's own global state is just broken. But you don't seem to believe this, so I'll let you discover it yourself. :) I agree with you that at some level there has to be a unique resource (for that computer), but it's not something I'd keep in a global variable. -- Lennart
On Wednesday 01 Dec 2004 12:07 pm, Lennart Augustsson wrote:
Adrian Hey wrote: It's not a language issue. It's a design issue. And in the case of device drivers you do want to pass the buck up to the layer that handles device drivers. Having each driver keep it's own global state is just broken. But you don't seem to believe this, so I'll let you discover it yourself. :)
For heavens sake, you're as bad as Keean. I was only saying that should be done for *unique resources*, and in the example I gave the device driver was a unique resource, as is often the case. But if that is not the case, and you have several of these devices then they collectively become a unique resource. Please stop assuming I am an idiot and address the issues.
I agree with you that at some level there has to be a unique resource (for that computer), but it's not something I'd keep in a global variable.
How would you implement this "global variable". In C? Regards -- Adrian Hey
Adrian Hey wrote:
I agree with you that at some level there has to be a unique resource (for that computer), but it's not something I'd keep in a global variable.
How would you implement this "global variable". In C?
I said I would NOT keep it in a global variable. :) Because I don't like them. -- Lennart
On Wednesday 01 Dec 2004 4:22 pm, Lennart Augustsson wrote:
Adrian Hey wrote:
I agree with you that at some level there has to be a unique resource (for that computer), but it's not something I'd keep in a global variable.
How would you implement this "global variable". In C?
I said I would NOT keep it in a global variable. :) Because I don't like them.
Oh yes, so you did. Sorry. What alternative would you propose? Something like Keeans thread talking to the rest of the world by channels? When Keean suggested this I objected that there was still no way to prevent accidental forking of multiple copies of this supposedly unique resource manager thread. (To enforce safety you still need to use oneShot or similar mechanism). But perhaps you have something else in mind? Regards -- Adrian Hey
Adrian Hey wrote:
Oh yes, so you did. Sorry. What alternative would you propose? Something like Keeans thread talking to the rest of the world by channels?
When Keean suggested this I objected that there was still no way to prevent accidental forking of multiple copies of this supposedly unique resource manager thread. (To enforce safety you still need to use oneShot or similar mechanism).
The top level loader controls how many times a device in initialised, and forks the manager thread. The "user" program is not given control until after all drivers are initialised, so there is no chance of the user being able to fork such a thread. Either way the point is moot, as I have shown how to start two copies of the driver even if it is protected with your onShot function (by replacing the MVar module) ... So I am now happy that the two proposals are equivalent. Keean.
participants (3)
-
Adrian Hey -
Keean Schupke -
Lennart Augustsson