What ever happened with Wimp2?
Eric Rucker
I haven't tried running it yet, but it looks like a good proof of
concept of putting a PMT layer on top of RISC OS, and allowing CMT
apps to run alongside it, to gradually move to a more PMT-compatible
system without having to rearchitect the entire OS in one go. Also,
the PMT layer could have support for multiprocessing, to take
advantage of multi-core CPUs (or a Hydra with five StrongARMs stuffed
in it, but that'd be bus starved anyway.)
Are there any downsides to such an approach? Yes, there'd have to be
bugs that would be worked out, and a CMT app could still bring down
the system, but the point is that apps could be modified to be PMT-
friendly, and the layer could be modified to support more and more of
what a CMT-only app would need to be safely preempted.
I'm aware that it wouldn't be as stable as starting with PMT, and
running CMT apps in a VM (being nearly the opposite of that approach,)
but it'd probably be a faster way to get some of the benefits PMT to
RISC OS, and break less stuff.
Theo Markettos
> It looks like the last release was in 1999.
>
> I haven't tried running it yet, but it looks like a good proof of
> concept of putting a PMT layer on top of RISC OS, and allowing CMT
> apps to run alongside it, to gradually move to a more PMT-compatible
> system without having to rearchitect the entire OS in one go. Also,
> the PMT layer could have support for multiprocessing, to take
> advantage of multi-core CPUs (or a Hydra with five StrongARMs stuffed
> in it, but that'd be bus starved anyway.)
The basic idea has been incorporated into the pthreads code that lives in
UnixLib. The pthreads implementation was just about the only useful code
from the long-dead Rozilla project, and as it turns out pthreads is a major
reason the Firefox port was feasible.
I'm not 100% sure but I think TaskWindow also works roughly this way.
The trouble with WIMP2 was that apps needed to be written specially for it.
The 'patch' to attempt to retrofit this was flaky in the extreme - not that
that was Niall's fault, it was just never likely to work too well.
Would a way forward not be to simply improve TaskWindow?
Whatever, the basic principle is a bit of a hack. So it would be better to
add OS-wide PMT rather than having to rely on a not-entirely-intended aspect
of callbacks.
Theo
druck
> It looks like the last release was in 1999.
>
> I haven't tried running it yet, but it looks like a good proof of
> concept of putting a PMT layer on top of RISC OS, and allowing CMT
> apps to run alongside it, to gradually move to a more PMT-compatible
> system without having to rearchitect the entire OS in one go.
Well the fact that it was very limited and caused lots of fatal hangs in
return for no appreciable improvement.
> Also,
> the PMT layer could have support for multiprocessing, to take
> advantage of multi-core CPUs (or a Hydra with five StrongARMs stuffed
> in it, but that'd be bus starved anyway.)
No it would not. It was just a way of making pre-empted calls to the
Wimp in certain circumstances (not in Wimp messages), it did not do
anything to address the fundamental single threaded nature of the OS and
3rd pary modules, which just cannot support access from more than one
tread (either on the same or different processors) for a large number of
APIs.
> Are there any downsides to such an approach? Yes, there'd have to be
> bugs that would be worked out, and a CMT app could still bring down
> the system, but the point is that apps could be modified to be PMT-
> friendly, and the layer could be modified to support more and more of
> what a CMT-only app would need to be safely preempted.
1) Where is the source? This is sort of thing you need the source for,
not that can be reverse engineered like 32bit compatibility.
2) Who's going to modify them? We can't find *ONE* developer to keep the
NetSurf front end alive, which is far more important than head in the
clouds stuff like this.
> I'm aware that it wouldn't be as stable as starting with PMT, and
> running CMT apps in a VM (being nearly the opposite of that approach,)
> but it'd probably be a faster way to get some of the benefits PMT to
> RISC OS, and break less stuff.
What is the point of an even less stable RISC OS?
---druck
Eric Rucker
> <snip>
I guess I should've replied with something like, "oh, ok, that makes
sense."
I'm pretty sure there is source included with the download, although
another issue is that it's GPL, which would be incompatible with the
Castle license.
And, the idea was "more stable and responsive than RISC OS is now,
even if it's less stable than doing it the right way," not "less
stable than RISC OS is now." I see that the benefit vs. effort isn't
favorable, and therefore it's not worth doing.
Jim Nagel
> ... putting a PMT layer on top of RISC OS, and allowing CMT
> apps to run alongside it, ...
a couple of abbreviations i've never seen before. is my guess right?
PMT = preemptive multitasking
CMT = cooperative multitasking
took me a couple of minutes till that penny dropped. i suspect i'm
not the only such reader.
as a general principle, 'twould be kind of the original poster to give
the full meaning before flinging an abbreviation!
--
Jim Nagel www.archivemag.co.uk
Eric Rucker
> a couple of abbreviations i've never seen before. is my guess right?
> as a general principle, 'twould be kind of the original poster to give
> the full meaning before flinging an abbreviation!
Sorry about that...